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Abstract 

I he constraint paradigm is a model of computation in which values are deduced whenever 
possible, under the limitation that deductions be local in a certain sense. One may visuali/c a 
constraint “program' as a network of devices connected by wires. Data values may How along the 
wires, and computation is performed by the devices. A device computes using only locally available 
information (with a few exceptions), and places newly derived values on other, locally attached 
wires. In this way computed values are propagated. 

An advantage of the constraint paradigm (not unique to it) is that a single relationship can 
be used in more than one direction. I he connections to a device are not labelled as inputs and out¬ 
puts; a device will compute with whatever values are available, and produce as many new values as 
it can. General theorem provers are capable of such behavior, but tend to sillier from combinatorial 
explosion; it is not usually useful to derive all the possible consequences of a set of hvpothes.es. The 
constraint paradigm places a certain k ind of limitation on the deduction process. 

I he limitations imposed by the constraint paradigm are not the only one possible. It is 
aigued, howevei, that they aic lestrictive enough to forestall combinatorial explosion in many in- 
tciesting computational situations, yet permissive enough to allow useful computations in practical 
situations. Moreover, the paradigm is intuitive: it is easy to visualize the computational effects of 
these particular limitations, and the paradigm is a natural way of expressing programs for certain 
applications, in particular relationships arising in computer-aided design. 

A tuunbei of implementations of constraint-based programming languages are presented. 
A progression of ever more powerful languages is described, complete implementations are 
presented, and design difficulties and alternatives are discussed. The goal approached, though 
not quite reached, is a complete programming system which will implicitly support the constraint 
paradigm to the same extent that I isi\ say, supports automatic storage management. 
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I T IS BY NOW a firmly established piece of the computer science folklore that all sufficiently 
powerful models of computation arc the same because they are all equivalent to a Turing 
Machine (this is known as Church’s thesis). Nevertheless, some models of computation are more 
tractable than others for certain purposes, and this is perhaps as much a matter of psychology as 
of computer science. Some models evoke mental images and analogies which others do not, and 
these images and analogies guide one’s thinking about a problem. Indeed, some models become 
so firmly entrenched in the folklore, or seem to correspond so naturally to the structure of certain 
classes of problems, that one’s instinctive approach when faced with similar problems is to turn to 
those models, and so such models become paradigm solutions for such problems. For example, the 
notion of a finite-state machine is so closely associated with the parsing of strings that whenever 
a problem of the form, “Scan a stream of things looking for some cumulative property” arises, 
my first thought is to frame the solution as a finite-state machine; therefore 1 assume that the 
solution may be of this form, and then try to fill in the details, and usually this approach works and 
occasionally not. 

Robert Floyd has remarked [Floyd 1979J: 

... continued advance in programming will require the continuing invention, elaboration, 
and communications of new paradigms. 

This dissertation is an exposition of one such paradigm: constraints. In this paradigm programs 
consist of statements of relationships among symbolically named quantities which are to be 
satisfied. What distinguishes a constraint-based language from others is the particular limitations 
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which arc placed on the deductive process which manipulates the relationships in order to produce 
values. 

In the cited work Floyd goes on to say: 

When a programming language makes a paradigm convenient. 1 will say the language 
supports the paradigm. When a language makes a paradigm feasible, but not convenient, 

I will say the language weakly supports the paradigm. ... most ot our languages only 
weakly support simultaneous assignment, and do not support coroutines at all ... Even 
the paradigm of structured programming is at best weakly supported by many of our 
programming languages. 

The constraint model of computation is not supported by any programming language in existence 
today: the closest approximation is probably PROLOG [Warren 1977b], The research I shall discuss 
here is an attempt to build a constraint-based language from the ground up. This includes 
definition of appropriate primitives, means of combining primitives, run-time support, means of 
abstraction, and a simple compiler. 

Again quoting from Floyd: 

A paradigm at an even higher level of abstraction than the structured programming 
paradigm is the construction of a hierarchy of languages, where programs in the highest- 
level language operate on the most abstract objects, and are translated into programs on 
the next lower level language. 

Phis is the paradigm used in the construction of the constraint system presented here. It was built 
on top of a LISP system, the dialect known as Lisp Machine LISP [Wcinrcb 1979], developed at 
M.I.T. In this dissertation I will not only describe the capabilities of the constraint system, but also 
describe its implementation, making remarks along the way on the techniques used to build large 
systems quickly and reliably. T hese techniques include data abstraction, debugging tools, defensive 
programming, and most particularly building on an existing system rather than re-implementing 
everything from scratch, lisp provides the user with a data structure printer, a parser, hashing 
of identifiers to data structures, automatic storage management, and a host of run-time facilities 
(arithmetic, search procedures, sorting, etc.) right off the bat; the incremental cost of constructing a 
new language is small. 

In summary, 1 will discuss three things in a somewhat mingled fashion: 

(1) The constraint model of computation, and some associated imagery. Phis will include a static 
relational model for the meaning of constraints, as well as computational models. 

(2) Methods of implementation, including consideration of alternatives. Possible data structures 
and control structures are compared. 

(3) Techniques for construction of large systems, using the constraint system as an example. This 
point receives somewhat less emphasis in the text, and is represented largely by side remarks 
and footnotes, and demonstrated by example. 
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1.1. The Constraint Model of Computation 

There are two images, or analogies, which 1 associate with constraints which make them useful 
to me. Neither of these is unique to constraints, but the combination is. 

The first image is that a constraint is a declarative statement of relationship. If I place a 
constraint that the quantity named a is less than the quantity named 6, then there is a known 
relationship between the two. Similarly, if the sum of three values z, y, and 2 is constrained to be 
zero, then there is a stated relationship among the three. This relationship can be viewed in more 
than one way: for example, one might find convenient for some purposes the asymmetric view that 
x is minus the sum of the other two. 

Predicate calculus and related description methods also model computation by stating 
relationships. Prcdicatecalculus-bascd programs such as PROLOG ([Warren 1977b]: sec also 
[Kowalski 1974]) provide both a relational model for interpretation of the meaning of the program, 
and a computational model for the algorithmic evolution of the canonical form for this meaning 
(the “output”). 

The second image is that a constraint is a computational device for enforcing the relationship. 1 
mean for the word “device” to be taken quite literally. I visualize a constraint as a little plastic box 
with metal pins coming out, just like the dual-in-line (dip) packages that digital integrated circuits 
come in. Just as a 7400 scries nand gate will force its output pin to be the logical negation of the 
logical product of its input pins, so a hypothetical 74000000 series nand constraint would constrain 
its three pins to obey the nand relationship. A constraint does not have designated “inputs” 
and “outputs”, however. At this level of abstraction I say nothing about how the relationship is 
enforced, except to say that the enforcement mechansisms arc (mostly) local to the device. 1 then 
visualize many of these little boxes being combined by running wires between their pins; these 
wires represent primitive equality relationships. A constraint program can be drawn very much like 
an electrical circuit diagram. (Indeed, it was research into analysis of electrical circuits that inspired 
the current Hurry of interest in constraints at M.l.T.fSussman 1975] [Stallman 1977]; and constraints 
in Sketchpad [Sutherland 1963] were also drawn as little “devices” connected by “wires” to their 
arguments.) As in an electrical circuit, all the devices are conceptually active at once; they operate 
in parallel. 

It is this computational metaphor that distinguishes constraints from, say, PROLOG. Both 
PROLOG and constraints are based on a statement of relationships, but they differ in the additional 
imagery. PROLOG restricts statements to Horn-clause form, and then likens such clauses to proce¬ 
dure declarations and imposes a backtracking procedure-calling metaphor. Constraints provide the 
metaphor of interacting discrete physical devices. Other metaphors may also be useful. 
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The data flow model of computation [Dennis 1973] [Dennis 1975] also takes a view of pro¬ 
gramming as the wiring together of devices which can then perform computations with as much 
parallelism is permitted by the wiring structure. Constraints arc like data flow in that one can 
visualize data as flowing from device to device along wires. The two differ in that data flow devices 
are directional, having specified input pins and output pins; constraints arc (in general) adircc- 
tional. Data flow can be considered to be a (perhaps very important) special case of the constraint 
paradigm. 

Analog computers also perform computations using devices which are wired together. They 
operate on a (conceptually) continuous domain, however, represented by voltages or currents. I 
focus here on constraints as a model of discrete computation, on discontinuous data domains. 
When discrete methods must be used rather than, say, relaxation techniques, the computational 
strategics arc radically different. 


1.1.1. Simple Statement of Relationships Constitutes Declarative Programming 

The advantage of a relational semantics for a programming language is that a static meaning 
can be assigned to the program independent of any computational model. This allows various im¬ 
plementations to be judged by a uniform standard, and a new implementation need not reproduce 
exactly the inessential quirks of an old one. Moreover, the program may well be easier to under¬ 
stand, and even (it is fashionable to say this nowadays) to prove. 1 

It has been argued [Pratt 1977] [Kowalski 1979] [Clark 1980?] that a program is best divided 
into two components, the competence and performance components (Pratt’s terminology, bor¬ 
rowed from Chomsky). The competence component contains factual information—statements of 
relationships—which must be manipulated and combined to calculate the desired result. The 
performance component then deals with the strategy and tactics of the manipulations and combina¬ 
tions. The competence component is responsible for the correctness of the program; the perfor¬ 
mance component is responsible for efficiency and termination. As an example, the following facts 
suffice for computation of the greatest common devisor r of two numbers x and y (the example is 
from Pratt, but the formulation is mine) 2 : 


l. Note also that it is easier to start with a good semantics and then implement it than to begin with an implementation 
and then derive (if one can!) some kind of post-hoc semantics (typically of the Royd-Hoarc style) to justify it. 


2. This formulation does not consist simply of universally quantified relationships about ged along with a request 
to find gc<l(j:, y)\ such is the nature of the formulation in [Pratt 1977], This formulation is somewhere between 
that and a deterministic algorithm, in that it expresses the idea that a sequence should be computed, that elements 
of the sequence may be computed according to a limited number of specified rules, and that some element of the 
sequence will be the result. 1'hus compared with Pratt’s version, this already outlines much of the strategy. The 
freedom remaining is the precise choice of rules used to compute the sequence. 
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zq — x z\ = y 

Vi > 2 (zi — Zi— i — Zi— 2 ) V (zi = Zi — 2 — 2,:- - 1 ) 
r = \z k \ wherez i+ i=0 

(Proof of formulation, using induction: certainly gcd(2*),zi) — gcd(z, y). Now suppose that 
gcd(^_ 1 ,^- 2 ) = gcd(j, y). Either 2 ,- = zi —1 —^—2 or z t = ^—2 — 2 ;— t- In the first 
case gcd( 2 f, 2 r*_i) — gcd(^_i — 1 ) = gcd(^_ 1 ,^— 2 ) — gcd(a;, y), and the other 

case is similar. Therefore for all i, gcd(^,^_-i) = gcd(z, y). Negative numbers do not matter, 
because we define gcd(— u, v) = gcd(u, v). Moreover, the fact that gcd(u, 0) — u means that 
r = gcd(x, y).) 

Now this set of rules is certainly competent; if a value is ever found for r, it will certainly be 
the ged of a; and y. Moreover, the declarative nature of the rules makes it easy to reason about 
them. However, the matter of performance is another tiling. A strategy is needed for making the 
choice at each step about which way to subtract. l ; or x — 15 and y — 12, one valid z sequence is 

15,12,3,9,6,3, 3,0 


whereupon r = 3. But another valid sequence is 


15,12, —3,9,12, 3, 9,6, -3,9,6, 3, 3, 0, -3, 3, 6, 3, 3,0 


whereupon r = 3 (the rules don’t say one must use the first zero value in the z sequence!). The 
computation may even fail to converge: 


15,12, -3,15,18, —3, 21, 24, -3, 27, 30, -3, 33, 36, -3, 39,... 


The behavior of the performance component cannot simply be left to chance; it can have a 
significant effect on the computational behavior of the system. (In some sense the only interesting 
difference between an n log n Quicksort and an n 2 Bubble Sort is performance.) 

We will posit the hypothesis that we would like, in our programming, to concern ourselves 
first with competence (correctness; “what”), and only then, if at all, worry about performance 
(efficiency; “how”). This implies that a programming language ought to allow the division of a 
program into the two separate components. Ideally, the computation could proceed, at some cost 
perhaps, without any advice on performance; but the more advice the programmer could give, the 
more efficient the computation could proceed. (Compare this with the declaration of data types in 
existing programming languages. In most of the algebraic 3 languages the declaration of data types 
is inextricably bound up with the rest of the program, even though the information is in many cases 


3. It used to be that “algebraic” meant “AI.GOI.-iike” or perhaps “FORTRAN-like”, but nowadays it seems to mean 
“PASCAL-likc”, for PASCAL is the currently popular, though poorer, re-invention of the excellent ALGOL wheel. 
Perhaps in another year, continuing the trend, the term will mean “ADA-like”. 
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redundant. To my mind that is one of the great advantages of interactive languages such as RASIC, 
API , and i isp: the programmer can proceed without ail the redundant baggage to the heart of the 
matter, and then go back later to add die declarations as documentation or advice. In MACLISP 
[Moon 1974], for example, one often writes a program without any declarations, and then adds 
numerical declarations later to advise the compiler how to go about getting EORTRAN-likc speed 
for numerical code [Fateman 1973] [Steele 1977]. T his is not to say that the programmer should 
not have the possibility of declarations in mind as he first writes the program. 1 would suggest, 
however, that programs written to try out an idea arc not necessarily best written using the same 
methodology with which one crafts the finished product.) 

As already mentioned, some other programming languages provide a means for this separa¬ 
tion of concerns. They arc pretty much alike in their expression of competence: one sugaring or 
another of predicate logic. (Kowalski states [Kowalski 1980]: ‘There is only one language suitable 
for representing information—whether declarative or procedural—and that is first-order predicate 
logic.” He may be right. 4 ) However, predicate-calculus-based programming languages differ in the 
automatic computational methods applied for performance purposes. 

In order that a constraint language behave as declarativcly as possible, we will posit this design 
goal (there will be others later): 

Design Goal 1 

As far as possible, the computational state of a constraint system should depend only 
on the relationships stated so far, and not on the order in which they were stated. 
(However, this order-independence is required only up to any ambiguities in the 
relationships.) 

A constraint program should have a clear declarative semantics unrelated to questions of or¬ 
dering and process. This is not to say that the results of a constraint program may be unaffected 
by the order in which things happen—but if ordering does matter, then it is because of an essential 
(possibly intentional) ambiguity in the stated relationships, in which case the system is explicitly 
free by fiat to make any choice among those possible. 


1.1.2. Constraints Use Local Deduction Techniques to Compute Solutions 

The very advantage of predicate calculus-like formalisms is that they inherently make no com¬ 
mitment as to computational technique; therefore predicate calculus is not a complete program¬ 
ming language. As noted in [Bobrow 1980]: 

[Predicate logic] is inadequate as a calculus because it does not make it perspicuous to 
model issues of memory and resource-limited reasoning ... 

4. Kowalski goes on to say, ‘There is only one intelligent way to process information—and that is by applying 
deductive inference methods. ITie AI community might have realised this sooner if it weren’t so insular.” ITiis seems 
a trifle strong to me. 
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And in [Sloman 1980]: 

When a new formalism is little more than a syntactic variant of predicate logic, translation 
is a useful debunking exercise. It is also useful in posing a challenge to clarify what 
the translation fails to capture, in other cases. More to the point, in some cases, would 
be translation into a good general-purpose programming language, e.g. LISP or POP2 
with records or property lists and a few general-purpose library routines. I shall start 
being impressed by new formalisms when they arc associated with powerful new useful 
techniques. [Italics his.] 


It is computational technique, rather than syntactic notation, which distinguishes predicate- 
calculus or relational programming languages. The difficulty with general theorem provers is the 
combinatorial explosion which results from simply trying to deduce all possible consequences from 
a set of statements. There must be some means of limiting this explosion in a useful way. Such 
limitations may of course prevent a computing system from arriving at a potentially deducible 
result, either absolutely (by totally preventing consideration of certain deductions) or relatively 
(by postponing the relevant deductions beyond an economically feasible amount of other com¬ 
putation). The challenge is to invent a limiting technique which powerful enough to contain the 
explosion, permissive enough to allow deduction of useful results in most cases of interest, and 
simple enough that the programmer can understand the consequences of the limiting mechanism. 
It is this last point which encourages the system designer to base the limiting mechanism on some 
easily grasped metaphor. 

In this dissertation 1 shall discuss the technique of local propagation. One can view the 
notion of local propagation from the declarative point of view: local propagation amounts to using 
only one relationship at a time to do arithmetic on known values (as opposed to using algebraic 
techniques for deriving new relationships by combining old ones). Of course, most programming 
languages share this same property; “algebraic” languages arc really arithmetic languages, and only 
the symbolic mathematical systems such as macsyma, rfducf, and scratchpad truly perforin 
algebra. A constraint-based language would be somewhere between the two types, differing from 
arithmetic languages in that the direction in which relationships were used would be determined 
dynamically, on an as-needed basis. As an example, in a constraint language, one would state 
a — b -}- c, or perhaps a — b — c — 0, or some such thing; this statement might then be used 
computationally to derive 6 given a and c. In an ALGOL-like language one must explicitly write 
b ■= a — c. This adirectionality is a property shared by symbolic algebra systems and deductive 
theorem provers; but then again, they arc oriented more towards algebra than arithmetic. By 
constrast, a constraint system avoids using the full power of algebraic transforms. 

Local propagation is perhaps more easily visualized in terms of the discrete device image, 
however. Think of a 74000083 full adder constraint device, in a five-pin package, the pins being 
a, 6, c, Vqq, and ground. Whenever any two pins have numbers on them, a value is computed 
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for the third pin. (It is partly by this means that die relationships are enforced; whenever a value 
is forced by others, it is immediately asserted.) If all three pins have numbers, and they don’t 
obey the relationship, then the device pushes back hard somehow, trying to make the numbers 
fit its relationship, or perhaps the device goes up in smoke if it doesn’t succeed. By analogy, 
consider a resistor, which takes two numbers, called voltage and current—which happen to be 
represented in an interesting physical way—on each of its two terminals, and enforces certain 
numerical relationships—also, as it happens, expressed in a physical way—among these numbers. 
An ideal resistor operates on a conceptually continuous physical domain, but we shall be interested 
here in discrete domains. The mental image of a physical device is apt, however; its operation is 
local in that it operates only on information immediately to hand on its pins. All the devices are of 
this form, and by cooperating in parallel they can produce global effects. 

One would expect that the constraint model might be a good model for multiprocessor com¬ 
putation for exactly the same reasons that data flow would be. Because each device computes 
when, and only when, the relevant information is available, a network of cooperating devices can 
exploit all possible parallelism in the computation. Constraints have the additional advantage that 
no prior commiunent need be made by the programmer as to which pins of a device arc input pins 
and which output, so a single network can be used to perform many different computations (not 
necessarily all at once, though). This generality of course has its price: a real hardware constraint 
architecture will be much more complicated than a data flow architecture. 

Although the constraint-system implementations discussed here arc in fact single-processor 
simulations, we would like the constraint model to serve as a model for parallel computation by 
machines each performing locally defined tasks. T herefore we posit another design goal: 

Design Goal 2 

As far as possible a constraint-based system shall perform its computations on the basis 
of locally available information only. 

We shall indeed achieve this goal for computations in which no conflicts occur; but that is 
of course the simple case. As we shall see, the constraint model is most useful for analyzing and 
dealing with conflicts. 


1.1.3. Constraint Networks Can Maintain the History of a Computation 

Because it is not determined a priori whether a given device pin will be used for input or out¬ 
put, neither is it determined in which direction data will flow along a wire (connection, equality). 
Suppose that associated with each wire is a bit, indicating in which direction data has flowed last; 
the value of the bit docs not matter if no data is on the wire. T hen, assuming that no conflicting 
values have arisen on a wire, when the computation has settled down (all possible local deductions 
having been made), various nodes of the network will have values, and the wires with values 
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will form a directed graph, with their bits indicating the directions, describing the history of the 
computation. Such a graph will constitute the particular data flow program traced out dynamically 
by the computation on an as-needed (or rather, greedy) basis. Because the graph indicates which 
values depend on which other values, it is said to encode dependency information ( dependencies for 
short). 

Such a history can be used for many purposes. It can provide explanations of the computation. 
It can also be used to resolve conflicts. If there is a loop in the network, then a value may propagate 
around the loop and compute a new and different value for the same quantity. In continuous- 
domain networks (such as electrical circuits) this is typically used to provide feedback effects which 
by relaxation cause the conflict to be resolved. Note that relaxation is of necessity a global, not 
local, process, because it is used to resolve conflicts caused by global properties of the network (the 
individual devices being assumed to be locally consistent). In the discrete-domain networks to be 
discussed here relaxation is replaced by the global processes of backtracking and resolution. 5 

The current work at M.l.T. on constraint-based computation was inspired by the need to 
analyze physical systems and to aid the engineering processes by which such systems arc designed. 
This dissertation began as an effort to provide a basis on which to build a design system for in¬ 
tegrated circuits. The intention was to provide the underlying mechanisms for recording design 
constraints, in the form of rules by which parts of the designed object interact, for integrated cir¬ 
cuits, some of these rules arc geometric in nature, some electrical, some logical, and some on more 
than one of these levels. The intention was to provide a uniform mechanism by which rules and 
values could be recorded, deductions made, and consequences asserted in a way that would interact 
well with the physical descriptions of the design. Moreover, the mechanism should automatically 
detect conflicts, and provide information to aid in explaining to the user the reason for the conflict. 
While the results of this research have not yet been incorporated into a design system, similar 
mechanisms have been used in design systems such as Daedalus [Shrobc 1980]. My intention is 
that the research presented here should serve as a basis for building a self-contained constraint- 
based language to serve as a host system on top of which to build design systems. The simple 
implementations presented here arc similarly built on top of a host I .ISP system. The constraint 
language will provide certain services to the implementor of a design system, such as recording 
design constraints and detecting and resolving conflicts, just as LISP provides certain services such 
as automatic storage management, which records given data in a structured form using a linear 
memory, and detects the implicit release of data structures and errors caused by incorrect access to 
structures. 


5. Relaxation and resolution are not interchangeable, but complementary, being applicable to different situations. 
A full constraint-based system would probably need to use both techniques; this was done in TI11NGI.AH [Horning 
1979], for example. In this dissertation, however, I arbitrarily focus only upon discrete domains, because relaxation 
has already been more throughly explored. 
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In this role as a design utility, a constraint system ought to have the property that it works if 
one gives it but a little information, and works better if one gives it more information. That is, the 
more relationships it has to work with, the more can be computed. Hence a third design goal: 

Design Goal 3 

A constraint-based system should, so far as possible, be monotonic. The more is 
known, the more can be deduced, and once a value has been deduced, knowing more 
true things ought not to capriciously invalidate it. 


1.1.4. Assumptions Provided Limited Non-nionotonic Behavior 

The word “capriciously” is included in Design Goal 3 for a reason. There arc some situations 
where it is useful to make assumptions, in order to provide “default” behavior. For example, one 
might want to say that an object can be oriented in any of several ways by rotation and reflection, 
but that some one orientation may be assumed unless explicitly proven otherwise. This is necessary 
to be able to draw a picture of an incomplete design, for example. If one knows that an inverter is 
part of a circuit in a particular position but the designer hasn’t yet specified whether it faces left or 
right, it is unsatisfying simply not to draw it; it might be better drawn in some default orientation, 
perhaps with an annotation to that effect. 

Unfortunately, introducing assumptions violates the principle of monotonicity, because infor¬ 
mation computed on the basis of an assumption may no longer be valid when the assumption is 
overridden. Therefore prov iding more information may cause fewer (though sounder) results to be 
known. We will permit this limited form of non-monotonicity, but nevertheless desire the results 
of computations to be relatively stable; hence a value, once computed, should not be retracted by 
caprice, but rather only because new information has definitely rules it out. Likewise, if either of 
two values is possible and one is (arbitrarily) chosen, then that value remains until rules out, rather 
than oscillation occurring. 

An assumption can be expressed as a deductive rule of the form “Deduce x = y provided 
that the system remains consistent.” Now of course consistency is a global property, and so an 
assumption mechanism also violates the design goal of locality. However, the rule can be phrased 
operationally as, “If one of x and y is known and the other not, deduce x — y," which is local, 
with the understanding that in the event of conflict a general global mechanism for conflict resolu¬ 
tion will hike over. This is in fact how assumptions arc implemented in the systems described in this 
dissertation. 

At least one dependency-recording system [Doyle 1978a] [Doyle 1978b] [Doyle 1979] has been 
so general as to allow deductions to be made on the basis of anything being unknown. Such a 
system has grossly non-monotonic semantics which leads to some logical difficulties. 'There has 
been some work done [McDermott 1979] on formalizing the semantics of non-monotonic logics. 
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These difficulties are avoided here by confining the non-monotonicity of the system to a fairly well- 
behaved special case. An assumption mechanism allows the constraint system to make guesses 
about possible extensions to the solution computed by local propagation, and thus provides a 
limited means of overcoming the limitations of locality. 


1.2. The Thesis 

• Constraints are a model for computation which has both a static declarative semantics and an in¬ 
tuitively appealing visualization as physical devices which perform dynamic local computations. 

• 'The constraint paradigm places limitations on the deduction process which arc stringent enough 
to prevent combinatorial explosion, loose enough to permit interesting computations to be per¬ 
formed, and sufficiently comprehensible to allow the programmer to predict the clfccts of the 
limitations. 

• Constraints provide a natural way to express and enforce the relationships of designed objects, 
and therefore a constraint-based programming language is a suitable base for building systems 
for computer-aided design (CAD). 

• A constraint system can easily retain information about the history of the computation which 
can be used to produce explanations of the system’s behavior, and to trace the root causes of 
conflicts. 

• Constraints include data flow as a special case. A suitable compiler can reduce a constraint 
program to a set of data flow programs, one for each possible partitioning of the program’s 
terminals into inputs and outputs. 

• Local propagation as the normal mode of computation, plus dependency-directed backtracking 
for resolving global conflicts, can serve as die implcmcntational basis of an expressively power¬ 
ful and potentially very efficient computational language. 

• A constraint-based language can be efficiently implemented by letting the structure of the im¬ 
plementation correspond in a direct way to the structure of the physical device imagery for 
constraints. 


1.3. Overview of the Dissertation 

This overview has two sections. One describes how this document was supposed to be or¬ 
ganized (and there arc reasons for describing diis, for it provides perspective on what was done and 
part of what remains to be done). The other section of course describes how it A organized. 
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1.3.1. The Author Had a Grand Program for Solving the Entire Problem 

When 1 set out to pursue this research, l had a plan, as many do. Phis dissertation was to 
have been divided into four parts with the following outline (this is not die actual outline for this 
dissertation), in which each italicized heading represents the title for one chapter: 

Original (Not Current) Outline 

Part I. Constraints. 

Propagation : implementing bidirectional devices which propagate values. 

Dependencies : recording computation histories and giving explanations. 

Retraction: using dependencies to resolve conflicts. 

Assumptions: limited non-monotonic computation based on guesses. 

Graphics: drawing constraint networks; constraints on graphical objects. 

Tables: handling compound objects such as arrays, whose values may be only partly known. 

Part II. Hierarchy. 

Abstraction: packaging networks to look like single constraint devices. 

Closures: devices as data objects; constraints on constraints; meta-circularity. 
l emmas: using hierarchy to guide the production of explanations. 

Part III. Algebra 

Notation: an abbreviated nested expression notation. 

Slices: aiding propagation through multiple redundant points of view. 

Transformations: pattern-directed invocation; automatic network augmentation; loop-breaking. 
Part IV. Efficiency 

Control: explicit control; propagation of desires; meta-constraints; heuristic assumptions. 
Specialization: case-splitting in the primitives to handle common situations quickly. 

Compilation: producing primitive devices from network specifications. 

Reclamation: garbage collection on the network; reclaiming reconstructive histories. 

(I do not expect the reader to comprehend the complete significance of all cryptic notes above. 
They are explained later in the dissertation.) 

As the research progressed, however, it became clear that within imposed time limits I had 
the choice of examining all of these topics in a cursory manner, or exploring a subset of them 
thoroughly. I chose the second option. 


1.3.2. The Author Settled for Doing Half Thoroughly Rather I lian All Poorly 

This dissertation docs not by any means encompass all of the material in the preceding 
outline, but that which is covered here is covered thoroughly. All but the last chapter (Conclusions) 
concerns existing constraint systems that have been demonstrated to work. All die code for all 
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these systems is included in this dissertation and documented in the text. 6 Not all the text concerns 
low-level details of the code, however. Kach chapter is typically split into a high-level discussion 
of issues, and a low-level discussion of implementation. I have attempted to arrange the text so 
that the reader may read the entire dissertation; or just the English text and not the code; or just 
the text, and skipping those sections which contain code. All sample computer input and output ap¬ 
pearing in the text are actual transcripts of the operation of the systems presented and documented 
in the text. 

This dissertation is divided into three parts. A condensed outline and a summary of each part 
and chapter follow. The arrangement of the material is vaguely similar to the originally proposed 
outline. The material in the above outline which docs not appear below is discussed at some length 
in the chapter on Conclusions. 

Brief Outline of Dissertation 

Part 1. Constraints. Propagation. Dependencies. Retraction. Assumptions. 

Part II. Engineering. Efficiency. Correctness. 

Part HI. Abstraction. Hierarchy. Compilation. 

Full Outline of Dissertation 

Part I. Constraints. In this part a constraint language is defined incrementally and the system 
for executing it implemented by stages. Kach chapter builds on the work of the previous one, until 
by the end of the part a moderately sophisticated constraint system has been constructed. 
Propagation. A minimal toy constraint language is defined; it permits the statement of equalities 
and some simple arithmetic relationships. An implementation representation is chosen, and LISP 
code for a constraint interpreter is presented. Sample runs of a trivial constraint program are 
exhibited, and some problems and deficiencies discussed. 

Dependencies. Mechanisms are introduced for recording the history of a computation. Utility 
procedures for extracting explanations from computation histories arc demonstrated. Ways of using 
the network as a symbolic (algebraic) representation of a quantity are discussed. 

Retraction. Conflicts can arise in a network in a number of ways; all are a consequence of global 
properties of the network. Hence a global process, dependency-directed backtracking, must be 
used to determine the precise causes of a conflict. Means of choosing which premise to retract are 
considered. 

Assumptions. Constructs arc introduced for advising the system on when to make assumptions or 
“educated guesses 1 ' about the value of some quantity. Such guesses may be inconsistent because 
of global considerations, and so nogood sets are introduced as a mechanism for recording in a 
locally accessible way the global reason for forbidding a guess. An implementation of assumption 


6. Ihe code is written in Lisp Machine LISP [Wcinrcb 1979], a dialect of LISP descended from MACLISP [Moon 
1974], Constructs which are peculiar to this dialect are described along the way. 
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mechanisms and automatic retraction of incorrect assumptions is presented. A large example (the 
n queens problem) is discussed and solved using a constraint program, which is shown to be 
potentially a more efficient technique than the usual chronological backtracking method. 

Part II. Engineering. The first part is concerned primarily with language definition and a clear 
and simple implementation which demonstrates the concepts involved. However, that implemen¬ 
tation is not particularly efficient, and is not obviously correct. This part contains a complete rc- 
impiementation of the same language, with issues of efficiency and correctness in mind. The entire 
state of the system is made explicit as data structures, rather than letting part be implicit in the 
program state of the I ISP code which implements the system. 

Efficiency. A complete re-implementation is presented of the language defined in the first part. 
Multiple reasons for a believing a value arc explicitly recorded. The computation rules arc pre- 
catalogucd to permit efficient dispatching. A queue-based control structure is introduced; the 
queues contain tasks to be scheduled, and most tasks compute for only a limited time, enqueuing 
other tasks. While priority ordering of tasks is introduced for efficiency, the tasks may be correctly 
scheduled in any order. Effort is expended to make it possible to characterize the state of the system 
at the time a new task is to be selected; this is intended to ease a demonstration of correctness. The 
state of the system when contradictions arc outstanding is still well-defined, and both explanation 
procedures and modifications to the network are designed to operate correctly even when the exist¬ 
ing network contains contradictions, flic queue-based structure is similar to that used by multi¬ 
programming schedulers, and is intended to mimic the standard single-processor simulation of a 
multi-processor system, thereby making it easier to transfer the ideas to a true multi-processor 
implementation. 

Correctness. This chapter contains no programs. It reflects on the implementation of the previous 
chapter. While no attempt is made to provide a rigorous proof of the implementation, a large 
number of the necessary invariants arc presented to sketch a possible approach to a proof. I he 
program is very large and would take considerable eff ort to prove rigorously. However, attention to 
the intended invariants stated here certainly aided the implementation process and served to detect 
many difficulties. 

Part HI. Abstraction The language developed in the first two parts has primitive devices and a 
means of combining them, but no means of abstraction for packaging up a combination to make it 
look like a primitive device. In this part we define a macro mechanism for this purpose. 

Hierarchy. The “flatness” of the language is relieved by introducing hierarchy in two ways. One 
is a macro mechanism by which a network can be packaged up and made to look like a primitive 
device; this induces a macro-call hierarchy. The other is a parser for a generalized nested algebraic 
notation, so that arithmetic expressions of roughly the usual sort can be used to notate constraint 
networks. The parser also implements convenient abbreviations. 

Compilation. When a macro device is instantiated, a copy of the defining network is produced 
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to perform the actual computations. Hence there arc no computation rules associated with macro 
definitions, but only with true primitive devices. In this chapter a compiler is described which 
from the network for a macro deduces all possible computation rules of interest and constructs a 
definition for an equivalent true primitive device. 

Conclusions. The research described in the dissertation is summarized. Tentative results not con¬ 
tained in the dissertation proper arc discussed, as well as foreseeable extensions to this work. Work 
by other researchers is discussed and compared with this research. 
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While constraints are superficially similar to fish, in actuality they are more 
closely related to alligators: they snap up their inputs greedily. Scaly green 
alligators swim lazily among the cypresses, evoking images of astronauts working 
in in silent, black space, their feet (almost non-existent in the case of alligators) 
dangling in whatever direction chance occasions, inasmuch as gravity is of little 
relevance in the void. 

In space, as elsewhere, except in swamps, and other places which are also 
exceptions to the rule, there are , generally speaking, no alligators , or for that 
matter their ostensible and ostentatious cousins, the ferocious (so people seem to 
think, in their dreams and fantasies, although / must say I cannot personally 
vouch for this notion as a hard and established fact) crocodiles. This is. however, 
a subject for fierce debate. 

—Anonymous 
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The mowin' of the mom in' 

'Midst the moanin' of the moon 
Bespeaks a specious speck of speech 
That quarters past the Noon. 

—Wall Kelly (1952) 

/ Go Pago 
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T he CENTRAL idea behind constraint-based systems is the notion of local propagation —that 
a number of small processes arranged in a network, each processing information locally 
and sending results on to neighbors, can cooperatively produce a useful global effect. The direction 
of computation is determined dynamically; a constraint attempts to enforce a relationship among 
several parameters without any prejudice as to which arc inputs and which outputs. It is willing to 
compute any parameter from others when those others have been determined. 

In this chapter we introduce a trivial constraint language. This language is exceedingly weak, 
and hardly useful for practical purposes. It is intended as a toy for didactic purposes. It has pur¬ 
posely been pared to the bone, stripped of all features not directly needed to illustrate the principle 
of local propagation. The implementation of this language is likewise trivial, and consequently 
suffers certain inefficiencies (which will be remedied in later chapters). 

2.1. A Trivial Constraint Language 

The data objects of our language arc the integers. 

It is possible to speak of an object without knowing precisely what it is by using a name for it. 
Such a name is a variable. A variable can be declared so: 

(variable x) 
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Then x is understood to denote an integer, though which integer it is may not yet have been 
computed. If the name x is mentioned later, it is understood to refer to this variable. 

An integer constant may be explicitly mentioned in the language by using the constant 
construct: 


(constant 43) 

In effect this declares an anonymous variable and also declares that the object named by this name¬ 
less variable is the integer 43. Of course, this is not very useful by itself; because the variable has 
no name, it cannot be referred to later. However, the form (constant 43) itself serves as a 
denotation of the variable, as will be seen. 

Two variables may be declared to denote the same object by using the == declaration: 


(== x y) 

As we shall see, the computational effect of this will be that when a value is computed for one 
variable, that will also become the value of the other variable. As a special case, one can assign a 
specific value to a variable by equating it to a constant: 


(== x (constant 43)) 


This states that the value of x is 43 (and also that die value of y is 43, since (== x y) is in 
effect). 

One can also state more complex relationships among variables by using constraints. We draw 
a constraint relationship as if it were a little TIT device. 1 l ogic devices, however, “compute” 
in only one direction—some pins only accept inputs and some only produce outputs—but our 
constraint boxes generally treat each “pin” as bidirectional. Fach pin of a constraint device is a 
variable: it has a name, and can be equated to other variables. 

Our language provides an assortment of devices for stating relationships among integers. In 
describing them, we list the name of the constraint type, the names of die pins, and the relationship 
enforced by the constraint. The pictures we will use for these constraints appear in Figure 2-1. 


adder {a, b, c} 
multipi ier {a, b, c} 


maxer {a, b, c} 


c = a -|- 6 (alternatively, a — c — 6 or 6 = c — a), 
c — a X 6 (alternatively, a = c/b or b — c/a). Note that c/b is not 
defined in this language if 6 = 0 or if c/b is not an integer. (When 
6 = 0 then c/b is many-valued (indeterminate) when c = 0, and 
no-valued (contradictory) when c ^ 0.) 
c = max(a, 6). 


1. Indeed, the inspiration for this computational paradigm was the mental imagery associated with electrical circuits. 
[Sussman 1975] [Stallman 1977] 
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liGURH 2-1. Primitive Constraint Devices on Integers. 





minner {a, b, c} c = min(a, b). 

equal ity {p, a, b} p <=> (a = b), where the truth value for p is represented by 0 for 

false or 1 for Uve, as in apl. 

gate (p, a, bj p =» (a — b ) (alternatively, (a 7^ b) =>~ p). 

No primitive is provided in the language for subtraction, because that is simply another way of 
viewing an addition constraint; similarly for division. More generally, a single constraint box can 
represent a given relationship and also all of its inversions. l ; or example, a single exponentiation 
box could represent all of a; == y z ,z = log x , and y = ^/x. 

ItiS In'TcRcStlnG TocOnSider die inversions of other operators as well—certainly they must 
be considered in order to provide a complete implementation of a constraint box for that operator. 
For example, what is the inversion of c = max(a, 6) which finds b given a and c? Let us denote 
this by arcmax r a. Then we can provide the following definition: 

I c ifa < c 

unknown ifa = c 

error if a > c 

Note that sometimes the value cannot be computed because the inputs are inconsistent (as in the 
case of dividing by zero), and so there is no consistent value. At other times die inverse may have 
multiple consistent values, and so no unique result can be computed. This occurs for arcmax c a 
when a — c, for the result can be any integer not greater than c. A more familiar example is that 
the square root operation is double-valued for positive inputs. We will return to this subject later. 

If we have several constraint boxes, we can “wire them together” by connecting their pins. 
Since each pin is a variable, two pins can be connected by equating them as variables. We indicate 
this in a diagram by drawing lines among the pins, according to the usual conventions of logic 
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diagrams. Textually, wc notate the interconnection of several constraints in two steps. First we 
declare and name instances of constraint devices: 

(create add adder) 

(create mult multiplier) 

(create otherinult multiplier) 

This creates an adder named add and two multipliers named mul t and othermul t. Next wc 
state the connections among the pins: 

(== (the b add) (constant 32)) 

( = = (the a add) (the a otherinult)) 

(== (the c othermult) (the c mult)) 

(== (the b othermult) (constant 5)) 

(== (the a mult) (constant 9))) 

We have used the the construct to refer to pins. The expression (the x y) refers to the pin 
named x of the device named y, and may be read “the x of y”. 

Let us also declare two variables f ahrenhe i t and cent igrade and connect them to (i.e., 
make them alternative names for) two pins: 

(variable fahrenheit) 

(variable centigrade) 

(== fahrenheit (the c add)) 

(== centigrade (the b mult)) 
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I he result is shown in Figure 2-2. This network in fact represents the familiar temperature conver¬ 
sion constraint between the variables fahrenheit and cent igrade. 2 

5 X (fahrenheit — 32) 

centigrade =--- 

9 

Suppose now, for example, that we state that centigrade is —40. 

(== centigrade (constant -40)) 

This results in the following sequence of computations: 

► From: centigrade =(the b mult) =—40 

(the a mult)=9 

the constraint mult deduces (the c mult) = —40 x 9 = —360. 

► From: (the c mult) = (the c othermult) = — 360 

(the b othermult) = 5 

the constraint othermult deduces (the a othermult) = (—360)/5 = —72. 

► From: (the a othermult) = (the a add) = —72 

(the b add) = 32 

the constraint add deduces (the c add) = (—72) -f~ 32 = —40. 

This computation is pictured in Figure 2-3. 

I his computational technique is called local propagation. Hach deduction is performed locally 
by a single primitive constraint device, from data immediately available to it. This results in a step- 
by-step propagation of values from one device to die next. 


2. Ill is example was borrowed in spirit from [Borning 1979], 
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Figure 2-4. Some Organizations for Implementing Cells. 


In summary, the statements permitted in our trivial constraint language are: 

• (create constraint-name constraint- type) , to create a constraint instance. 

• (variable variable-name ), to declare a global variable. 

• (= = thing-1 thing-2), to equate two variables. 

The forms that may be mentioned in a == statement are: 

• variable-name, the name of a declared global variable. 

• (the pin-name constraint-name), which means the pin pin-name of the created constraint 
constraint-name. 

• (constant integer), which effectively means an anonymous variable with integer as its as¬ 
sociated value. 

The constraint-types provided by the language arc adder, multiplier, maxer, minner, 
equal i ty, and gate. 

2.2. Implementation of a Trivial Constraint Language 

Here we discuss a complete implementation of our trivial constraint language in lisp (more 
specifically, Lisp Machine LISP [Weinreb 1979]). First we describe the data structures used to 
represent variables and values; then the representation of constraints; after that, the “evaluation 
mechanism” which effects computation by local propagation; and finally, definitions of primitive 
constraints. 


2.2.1. Cells arc Used to Represent Variables 

A cell is a data structure used to represent a variable. It is used not only to contain a value, but 
to record the equating of the variable to other variables. 
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Equating of variables is transitive. Whenever a value is determined for one variable, then all 
variables equated to it must also receive that value, and all variables equated to them , and so on. 
This fact constitutes a propagation requirement. 3 Variables transitively equated obviously form an 
equivalence class. This class can be organized in one of several ways for purposes of propagation. 

(a) All equivalences arc explicitly recorded. Each cell contains the set of all cells to which it has 
been directly equated; call this set its neighbors. When a cell receives a value, the value is 
propagated to its neighbors, which will recursively propagate it. (See Figure 2-4a.) 

On a sequential machine this technique requires space linear in the number of equivalences 
(which may be anywhere from linear to quadratic in the number of cells); constant time to add 
an equivalence; and time linear in the number of equivalences (between linear and quadratic 
in the number of cells) to propagate a value throughout the class. A recursive propagation 
procedure is required. 

(b) The transitive closure of the equivalence relationship is explicitly recorded. Each cell contains 
the set of all cells to which it is transitively equivalent. If an equivalence is added between two 
cells not of the same class, then every cell of each class must have all cells of the other class 
added to its set. When a cell receives a value, then it sends the value to each neighbor, but no 
recursive propagation is required. (See Figure 2-4b.) 

On a sequential machine this requires space quadratic in the number of cells; time linear in the 
number of cells to add an equivalence; and time linear in the number of cells to propagate. 'Hie 
propagation procedure is simpler, however, being iterative. 

(c) Note that in the previous technique all the sets of neighbors would be identical if a cell were 
considered its own neighbor. Therefore let this set be represented only once and be shared 
among all cells. Furthermore let the value not be propagated at all, but be stored in only one 
shared place. (See Figure 2-4c.) 

On a sequential machine this requires space linear in the number of cells; time linear in the 
number of cells to add an equivalence (because a new set of neighbors must be constructed— 
the perhaps simplistic assumption here is that it takes linear time to take the union of two sets 
of neighbors); and constant time to propagate. 

We choose the last option for reasons of performance and pedagogy. 4 (The time to create n equiv¬ 
alences is still quadratic in n (because each one can be linear in the number of equivalences already 
made). It would be possible to use even more clever techniques but we shall forego that here.) 

Let us therefore define a cell to be a data structure with four components: 


3. I equality is therefore a special kind of constraint which also performs local propagation of values. It could be 
represented in the same way as other constraints, but for the fact that we intend to use equality itself as the means 
for connection of devices. Hence equality must be handled specially to avoid infinite regress. 


4. And perversity? We shall see that this cleverness makes things difficult later, when compound objects and 
dependencies are introduced. We shall then have to choose another representation. 



44 


Chapter Two 


Propagation 



Figure 2-5. Three Equivalent Cells with Value Five. 


(1) An identification id, used primarily for user meta-language interaction and debugging. (This 
component is not essential to the computational ability of the system.) 

(2) An owner, which may be null (indicating that the cell represents a globally named variable), or 
may be a constraint (in which case the cell is a pin of that constraint). 

(3) A name , which is a global name if the owner is null, or the pin name if the owner is a 
constraint. 

(4) A repository, which is a data structure representing things shared with other cells. 

Names of variables should be unique; hence all the cells with the same owner should have distinct 

names, and all the global cells should have distinct names. As an exceptional special case, all 

constants have a null owner and the name 

Similarly, we define a repository to be a data structure with three components: 

(1) A llag boundp , indicating whether or not a value has been computed for this equivalence class 
of cells. 5 

(2) T he contents, which is the computed value if the boundp flag is true. 


5. Instead of having a separate flag, one could simply have a reserved value (nil or "unbound” or something) 
indicate the absence of an explicitly computed value. This technique can save space in an efficient implementation. 
We choose to use a flag here for clarity. 
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(deftype repository ((rep-contents ()) (rep-boundp ()) (rep-cells '())) 
(format stream "<Repository":for ~{~S~t 
(rep-boundp repository) 

(rep-contents repository) 

(cell-ids repository))) 

(defmacro node-contents (cell) ‘(rep-contents (cel 1-repository ,cell))) 
(defmacro node-boundp (cell) ‘(rep-boundp (cel 1 - repository ,cell))) 
(defmacro node-cells (cell) ‘(rep-cells (cel 1-repository ,cell))) 

(deftype cell (cell-id cel 1-repository cell-owner cell-name) 

(format stream "<~S~:[~2*~; (~S of ~S)~]: ~:[~*no value~;~S~J>" 

(cel 1 - id cell) 

(cell-owner cel 1) 

(cel 1-name cell) 

(cell-owner cell) 

(node-boundp cell) 

(node-contents cell))) 

(defun cell-ids (rep) 

(forlist (x (rep-cells rep)) (cell-id x))) 

Tahi r 2-1. LISP Code Defining Cell and Repository Data Types. 


(3) The cells, a list of all cells which have this data structure as its repository. Thus this constitutes a 
set of back-pointers. From any cell all cells to which it is equivalent can be discovered. 

Figure 2-5 shows three cells which have been equated and given the value 5. One cell is the c pin 
of an adder constraint; the one with name ? is a constant (which was probably the source of the 
value 5); and the one with name fahrenheit is a globally named cell. 

It is often convenient to consider a repository and all its associated cells to be a single object; 
we shall call such a collection a node, because it corresponds to a node of a network graph in the 
pictorial representation. A node is the conjunction of two or more arcs (edges, wires). Alternatively, 
a node represents an equivalence class of variables. We can draw a fine distinction by speaking of 
a value as being associated with a node or with a cell; the former case is a simple statement that 
all the cells of the node have the same value, but in the latter case we draw specific attention to an 
important relationship between the value and that particular cell of the node. 

The lisp code in 'fable 2-1 defines cel 1 and repository to be LISP user data types. Bach 
deftype definition of the form 

(deftype name ( component-1 component-2 ...) printer) 

defines a new user data type called name. This will be a record-style data type with a fixed number 
of named components. It implicitly defines a number of functions to perform construction, selec¬ 
tion, and predication for that type. Also, the method for printing objects of that data type is 
specified. Once the type definition above has been made; 
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• (make - name) will create and return a new data structure of type name. 

• ( name- p a) is a predicate true iff a is of type name. 

• (require - name x) signals an error if a is not of type name. This is useful for error- 
checking and in-code documentation. 

• Each component-] in the definition specifies the name of one record component. The component- 
jam be of cither the form cname or the form ( cname initval ) . In either case cname is the 
name of a component of the data structure, and is the name of a selector function (actually a 
i ISP macro) for extracting that component from an object. Thus ( cname x) will return the 
contents of the cname component of the object a, which must be of type name. Moreover, the 
form (setf ( cname a) newval) will change the cname component of a to be newval. If 
the first form for component-/ is used, then the component value of a newly created instance of 
type name is undefined; otherwise, the component is initialized to initval . 6 

• The form printer is used by the I ISP system to print objects of type name. Within the printer 
form the variable name names the object to be printed and the variable stream names the 
stream to which to send the output. The details of the format function arc unimportant here; 
examples of printed objects will appear later. 

As an example, the definition of repository in Table 2-1 defines the function make-repos i tory 
of no arguments, which generates an object of type repository with three components 
named rep-contents, rep-boundp, and rep-cells. It also defines three functions 
rep-contents, rep-boundp, and rep-cell s which extract conponcnts from objects of type 
repository. Saying (setf (rep-contents x) 43) takes the value of the MSP variable 
x (which must be a repository) and alters its rep-contents component to be 43. The func¬ 
tion repository-p is a predicate which can be applied to any MSP datum, but is true only 
of repositories. The procedure requi re-repos i tory signals an error if its argument is not 
a repository. Finally, a repository with no value and two cells in its list of cells might print as 
“<Reposi tory for CELL-34 ,CELL-36V’. 

Table 2-1 defines not only the data types cel 1 and repos i tory, but also some extra mac¬ 
ros for dealing with nodes. We do not define a separate i isp data type called node; instead, any 
cell of a node may serve to represent the node. The repository of a node holds data belonging 
to the node, and so the macros get the repository of the given cell and then extract the desired 
information from the repository. Thus, for example, 

(node-contents x) —► (rep-contents (cel 1-repository x)) 
and similarly for node-boundp and node-cells. 

6. As a matter of programming .4ylc, I have written initialization forms iff the program depends on those initial 
values; components with no default values specified in the def type declaration must be initialized by the program 
before being read. Another quirk of my programming style is that I write () to mean the constant “false” and ’() 
to mean the constant “null list”. Some LISP systems do not identify the null list with the atomic symbol NIL. 
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(defun gen-cell (&optional (name '?) (owner ())) 

(and owner (require-constraint owner)) 

(let ((c (make-ce11)) 

(r (make-repository)) 

(n (gen-name 'cell))) 

(setf (cell-id c) n) 

(set n c) 

(setf (cell-owner c) owner) 

(setf (cell-name c) name) 

(setf (cel 1-repository c) r) 

(push c (rep-cells r)) 

c)) 

(defun constant (value) 

(let ((cell (gen-cell))) 

(setf (node-contents cell) value) 

(setf (node-boundp cell) t) 
cel 1)) 

(defmacro variable (name) ‘(setq ,name (gen-cell ',name))) 

Table 2-2. Creation of Cells, Constants, and Variables. 


VALUE CELL 
PRINT NAME 
ETC. 



Figure 2-6. The Result of the Creating a Pin for an Adder. 


Some utility procedures for generating new cells arc shown in Table 2-2. The function 
gen-cell generates a new cell with given name and owner (if omitted, then the name is ? 
and the owner is null). A non-null owner must be a constraint (this is checked and enforced 
by the call to requi re-constraint in gen-cell). A new name of the form cell - nnn 
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is created for the cell; this is a (global) I ISP variable which receives the cell as its value. This 
fact is of no consequence in the constraint computation proper, but is useful for mcta-linguistic 
and debugging purposes. A repository is also created for the cell and linked up to it; thus every 
newly created cell constitutes a new node unto itself. Figure 2-6 shows the result of the call 
(gen-cell 'c adder-27). 

Saying (constant 5) will generate a new cell whose value is 5 (and whose boundp flag 
has been set true!). 7 Saying (variable foo) will cause the global I iSP variable named foo to 
have as its value a cell whose global name is also foo. 


2.2.2. Constraints are Instances of Constraint- types 

Just as in implementations of ordinary programming languages one conveniently divides a 
procedure into a constant part (the program text) and a variable part (parameters), so it will be 
convenient to split off the constant part of a constraint. We will call this the “constraint-type”. A 
constraint-type contains the “program text” (rules for computation in various circumstances), its 
own name (for identification purposes), and the names of parameters. 

Any given instance of this constraint-type we call a constraint. Such an instance refers to its 
constraint-type for the sake of the constant information the latter contains. The constraint also has 
a list of parameter “values” which correspond to the parameter names in the constraint-type. These 
“values” are actually cells used to contain the values. Finally, each constraint has a generated id and 
a global user name in the same way each cell does. 

fable 2-3 gives definitions for the data structures constraint-type and constraint. 
The function gen-constraint creates an instance of a given constraint-type. It invents a name 
for the constraint instance; if the name of die constraint-type is bazola, then the name of the 
instance will be bazol a- nnn. It also creates new parameters cells to serve as pins. Figure 2-7 
shows the data-structure representation of an adder. 

In Tabic 2-4 is the code for implementing the the construct for referring to the pins of a 
constraint. The implementation is in layers. First, the macro the is purely a bit of syntactic sugar 
for a call to the functon *the, to avoid having to write a quote mark. 8 The function *the in 
turn calls lookup to do the real work, signalling an error if lookup fails to locate the pin. Now 

7. The reason for using the constant construct in our constraint language is purely pragmatic: we wish to use the 
standard MSP evalualor to do as much work as possible for us. by conforming to a few restrictions we can arrange 
for all construct of our language to be executable MSP code with the proper effect: this saves us the work of writing 
our own language interpreter (in much the same way that conforming to the usual parenthetical MSP syntax saves 
us the work of writing an input parser, because we can simply use the standard MSP function read). If we were 
willing to write our own interpreter, then that interpreter could unambiguously interpret an integer to mean a cell 
containing that integer, for example. 


8. This is an example of wanting MSP to do the work without fully accommodating LISP syntax. Macros allow a 
slight bending of the rules. 
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(deftype constraint-type (ctype-name ctype-vars (ctype-rules '())) 

(format stream "<Constraint-type ~S>” (ctype-name constraint-type))) 

(deftype constraint (con-id con-name con-ctype con-values) 

(format stream j SV (con-name constraint) (con-id constraint))) 

(defmacro create (name type) k (setq ,name (gen-constraint ,type ',name))) 

(defun gen-constraint (ctype) 

(require-constraint-type ctype) 

(let ((c (make-constraint)) 

(n (gen-name (ctype-name ctype)))) 

(setf (con-id c) n) 

(set n c) 

(setf (con-name c) name) 

(setf (con-ctype c) ctype) 

(setf (con-values c) 

(forlist (var (ctype-vars ctype)) 

(gen-cel 1 var c))) 

c)) 

Tahi.k 2-3. Constrainls and Constraint-Types. 


(defmacro the (x y) ‘(*the ',x ,y)) 

(defun *the (name con) 

(require-constraint con) 

(or (lookup name con) (lose "~S has no part named ~S." con name))) 

(defun lookup (name thing) 

(require-constraint thing) 

(do ((names (ctype-vars (con-ctype thing)) (edr names)) 

(cells (con-values thing) (edr cells))) 

((null names) ()) 

(and (eq (car names) name) (return (car cells))))) 

Tabu* 2-4. Referring to Pins of a Constraint Device. 


1 ookup merely searches the list of parameter names in the constraint-type of the constraint, and if 
die given name is found it returns the corresponding cell. 


2.2.3. Equating of Cells Links Them and Propagates Values 

In §2.2.1 we saw that c'/cry newly created cell has its own associated repository, and so is a 
minimal-size node. More generally, of course, every cell must always have a repository, which may 
be shared with other cells to form a larger node. 
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The constraint-type ADDER 



FlGURH2-7. The adder Constraint-Type and an Instance. 


When two cells arc equated, then one repository is no longer needed. For simplicity and sym¬ 
metry we shall simply throw them both away and create a new one, about which a node containing 
all the cells of die two input nodes is built. 
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(defun == (celll cell2) 

(require-cel 1 celll) 

(require-celI cell2) 

(or (eq (cel 1 - repository celll) (cel 1-repository cell2)) 

(let ((r (make-repository)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp cel 12))) 

(setf (rep-boundp r) (or cbl cb2)) 

(setf (rep-contents r) (merge-values celll cell2)) 

(setf (rep-cells r) (append (node-cells celll) (node-cells cel 12))) 
(let ((newcomers (if cbl 

(if cb2 '() (node-cells cel!2)) 

(if cb2 (node-cells celll) '())))) 

(dolist (cell (rep-cells r)) 

(setf (cel 1-repository cell) r)) 

(dolist (cell newcomers) 

(cond ((cell-owner cell) 

(ctrace "Awakening ~S because its ~S got the value ~S." 
(cell-owner cel 1) 

(cell-name cell) 

(rep-contents r)) 

(awaken (cell-owner cell))))) 

'done)))) 

(defun merge-values (celll cell2) 

(require-cel 1 celll) 

(require-cel 1 cell2) 

(let ((vail (node-contents celll)) 

(va!2 (node-contents cel!2))) 

(cond ((not (node-boundp celll)) val2) 

((not (node-boundp c e112)) vail) 

((equal vail val2) vail) 

(t (lose "Contradiction between ~S and ~S." celll col 12))))) 

(defun awaken (con) 

(require-constraint con) 

(dolist (rule (ctype-rules (con-ctype con))) 

(funcal 1 rule con ))) 

Table 2-5. Equating of Cells and Propagation of Values. 


Tabic 2-5 shows how two cells arc equated. The function == takes two cells, and if they 
arc not yet equivalent it creates a new common repository for them. This repository will have a 
value if either of the input nodes had a value. Moreover, if both nodes had values, then when 
they are equated the values must coincide. The contents for the new repository arc calculated by 
the function merge-values, which merely decides which node’s value to use, and if both have 
values checks that they are equal, signaling a contradiction otherwise. 9 The new repository’s set 
of cells is die union (which must in fact be a disjoint union) of the sets of cells for the two cells’ 
repositories. The newcomers arc defined to be those cells which formerly had no value but will 


9. When new features arc added to the language later, merge-values will have the more complicated task of 
merging two structured objects, taking some attributes from each value. 
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{declare (special -^tracing*)) 

(setq *tracing* t) 

{defun trace-on () (setq ^tracing* t)) 

(defun trace-off () (setq ^tracing* ())) 

(defmacro ctrace (string . args) 

‘(and ^tracing* (format t |~1@{~:}" ,string ,@args))) 

Table 2-6. A Simple Tracing Mechanism. 


now have a value because of the new equivalence. There can be newcomers only if exactly one 
node had a value, in which case the cells of the other node arc the newcomers. 10 After all the cells 
involved are hooked up to the new repository, the owner (if any) of each cell is awakened. The 
function awaken when applied to a constraint runs all the rules associated with that constraint, 
telling each rule which constraint instance was involved (because the rules of a constraint-type are 
shared among all instances). 

The ctrace statement is included purely for debugging purposes. It prints a formatted mes¬ 
sage so that the inner workings of the system can be traced. The lisp code for ctrace is shown 
in Table 2-6. The arguments to format are rather cryptic, but an obvious feature of the ctrace 
facility is that it can be turned off! The functions trace-on and trace-of f set and clear the 
global tracing flag. 


2.2.4. Constraints Are Implemented as Sets of Rules 

The implementation of primitive constraint devices is best seen by example. Tabic 2-7 con¬ 
tains the 1 ISP code for the devices whose symbols appeared in Figure 2-1. Rach is expressed in 
terms of a special macro de f p r i in: 

(d e f p r i m name pin-names 

( input pins- / rule-body-1) 

( input-pins-2 rule-body-2) 

( input-pins-n rule-body-n)) 

This defines a constraint-type called name which has parameter names pin-names. Rach rule has a 
list of input pins and a piece of code 11 to execute when those pins all have values. (This restriction 
is simply a convenient filter which all rules desire. Recall that the function awaken given in Table 
2-5 runs all the rules for a constraint. We shall see that defprim provides the code to check for 

10. Again, when the task of merye-values will be to merge two structured objects, the cells of both nodes may 
be newcomers. We will see this later. 


11. Ibis code is not written in the constraint language, but in the implementation language: these definitions are for 
primitive constraints, later we shall consider the definition of non-primitive constraints. 
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(defprim adder (a b c) 

((a b) (setc c (+ a b))) 

((a c) (setc b (- c a))) 

{(b c) (setc a (- c b)))) 

(defprim multiplier (a b c) 

((a) (and (zerop a) (setc c 0))) 

((b) (and (zerop b) (setc c 0))) 

((a b) (setc c (* a b))) 

((a c) (and (not (zerop a)) (zerop (\ c a)) (setc b (// c a)))) 

((b c) (and (not (zerop b)) (zerop (\ c b)) (setc a (// c b))))) 

(defprim inaxer (a b c) 

((a b) (setc c (max a b))) 

((a c) (cond ((< a c) (setc b c)) 

((> a c) (contradiction a c)))) 

((b c) (cond ((< b c) (setc a c)) 

((> b c) (contradiction b c))))) 

(defprim minner (a b c) 

((a b) (setc c (min a b))) 

((a c) (cond ((> a c) (setc b c)) 

((< a c) (contradiction a c)))) 

((b c) (cond ((> b c) (setc a c)) 

((< b c) (contradiction b c))))) 

(defprim equality (p a b) 

((p) (or (= p 0) (= p 1) (contradiction p))) 

((a b) (setc p (if (= a b) 1 0))) 

((p a) (and (= p 1) (setc b a))) 

((p b) (and (= p 1) (setc a b)))) 

(defprim gate (p a b) 

((p) (or (= p 0) (= p 1) (contradiction p))) 

((a b) (or (= a b) (setc p 0))) 

((p a) (and (= p 1) (setc b a))) 

((p b) (and (= p 1) (setc a b)))) 

Tablh 2-7. Implementation of the Constraint Boxes of Figure 2-1. 


each input cell having a value.) Thus we implement our non-directional constraint boxes in terms 
of a directional language such as MSP. 

Consider the definition of the adder constraint. It specifies three rules. When any two values 
are known, the third can be computed by the rules c +— a -f- 6, b <— c — a, and a <— c — b. "ITie 
form (setc c (+ a b )) means “set cell c to the value of (+ a b)”. 

Cook now at the definition of multiplier. It has rules which compute new values condi¬ 
tionally. For example, a value for c can be computed from a alone provided that a is zero. 
Similarly, computing b from a and c is conditional on being able to express the result as an 
integer (that is, the remainder (\ c a ) must be zero). The LISP value produced by the rule-body 
computation is ignored; only the setc construction specifics new values for cells. 
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Next reflect upon the definition of maxer. When a and c are known, then as wc saw in §2.1 
there are three cases for computing arcmax r a. If a < c then 6 c; if a = c then b is unknown; 
and if a > c then it is not a matter of computing b at all: it is simply a contradiction, a violation 
of the constraint. This is all expressed in the second rule for maxer(thc case a — c implicitly 
holds if both cond tests fail). The form (contradiction a c) signals that a contradiction 
has occurred, and that the values of cells a and c are at fault. 

Digression .There is another implementation strategy which does not require the use of setc at all, which 
was used in the constraint system reported in [Steele 1979]; that paper did not describe the technique, 
however, and therefore it is outlined here. It is assumed that each rule computes a value for exactly 
one cell, and that this value is computed by the rule-body; thus the t.iSP value of the rule-body actually 
is used. F.ach rule is therefore defined by a list of input cells, a rule-body, and an output cell. There 
are two global variables *lose* and *dismiss*. whose values are distinguishable from any value 

normally computed by a rule. If the value of a rule-body is that of* lose*, then a contradiction is 

signalled (the assumption being that it is precisely all the input cells that are at fault). If the value is 
that of *dismiss*. then no value is specified into the output cell. The definition of maxer using this 
technique would be; 

(defprim maxer (a b c) 

(c (a b) (max a b)) 

(b (a c) (cond ((< a c) c) 

((> a c) *lose*) 

(t *dismiss*))) 

(a (b c) (cond ((< b c) c) 

((> b c) *lose*) 

(t *dismiss*)))) 

One advantage of this technique is that one is required to cover all cases explicitly. On the other 
hand, it may require duplication of code if the same tests are used in rules for setting more than one 
cell (which, however, is not the case for the constraints of Table 2-7). Also, each rule is required to 
specify an output pin, which for some rules may be irrelevant. Consider the first rule of equality in 
Table 2-7, for example; it merely performs a consistency check on the pin p. It never computes a new 
value; the only possible outcomes are contradiction or dismissal. 

This techique is useful in some situations, however, and we will use a variant of it in a later 
implementation. For now, however, the use of setc seems more instructive and intuitively appealing. 

Note that the two values *dismiss* and *lose* of this technique may be interpreted to mean 
J_ and T, extra values adjoined to the value domain to represent under- and over-constrained values. 

(End of digression.) 

'The 1.JSP macro definition of the defpr im construction (Fable 2-8) is rather involved, but 
its effect is straightforward. It declares name to be a global LISP variable, and sets that variable 
to a newly created constraint-type data structure. T he name and pin-names arc installed in this 
structure, and then the rules arc defined using the def rule construct. The def rule construct 
arranges for the LISP variable *me* to be bound to the constraint for which this rule is being 
invoked (the constraint which was awakened). T he code for each rule binds variables named 
pin- name- cel 1 for each pin of the constraint, and then checks to see that the input pins for that 
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(defmacro defprim (name vars . rules) 

‘(progn 'compile 

(declare (special ,name)) 

(setq ,name (make-constraint-type)) 

(setf (ctype-nanie ,name) ',name) 

(setf (ctype-vars ,nanie) ',vars) 

,@(forlist (rule rules) 

‘(defrule ,name 

(let ,(forlist (var vars) 

‘(,(symbol cone var "-CELL") (the ,var *me*))) 

(and ,@(forlist (var (car rule)) 

‘(node-boundp ,(symbol cone var "-CELL"))) 

(let ,(forlist (var (car rule)) 

‘(,var (node-contents ,(symbolconc var "-CELL")))) 

,@(cdr rule)))))) 

' ( ,naine pr imitive))) 

(deFmacro defrule (typename . body) 

(let ((rulename (gen-narne typename 'rule))) 

‘(progn 'compile 

(push ',rulename (ctype-rules ,typename)) 

(defun ,rulename (*me*) ,@body) 

'(,typename rule)))) 

Table: 2-8. Definition of Primitive Constraints and Rules. 


(progn 'compile 

(push ' equal ity-rule-23 (ctype-rules equality)) 

(defun equality-rule-23 (*me*) 

(let ((a-cell (the a *me*)) 

(b-cell (the b *me*)) 

(p-cel1 (the p *me*))) 

(and (node-boundp a-cell) 

(node-boundp b-cell) 

(let ((a (node-contents a-cell)) 

(b (node-contents b-cell))) 

(setc p (if (= a b) 1 0)))))) 

'(equality rule)) 

Table 2-10. Expanded Second Rule of the equal ity Constraint. 


rule are hound. If so, then the rule-body appearing in the defprim construct is executed. Table 2- 
9 shows the I.ISP code into which the call on defprim macro for adder expands. 

The defrule construction simply generates a name for the rule, and defines a i isp function 
by that name. T his function takes one argument, a constraint, calls it *me*, and executes the rule 
code. T he name of the function is also added to the set of rules in the constraint-type. Table 2-10 
shows the LISP code into which the second defrule in fable 2-9 expands. 

Table 2-11 shows the implementation of contradiction and setc. An invocation of 
contradiction expands, for example, as: 
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(progn 'compile 

(declare (special equality)) 

(setq equality (make-constraint-type)) 

(setf (ctype-name equality) 'equality) 

(setf (ctype-vars equality) '(a b p)) 

(defrule equality 

(let ((a-cell (the a *me*)) 

(b-cel1 (the b *me*)) 

(p-cell (the p *me*))) 

(and (node-boundp p-cell) 

(let ((p (node-contents p-cell))) 

(or (= p 0) (= p 1) (contradiction p)))))) 

(def rule equality 

(let ((a-cell (the a *me*)) 

(b-cell (the b *me*)) 

(p-ce 11 (the p *me*))) 

(and (node-boundp a-cell) 

(node-boundp b-cell) 

(let ((a (node-contents a-cell)) 

(b (node-contents b-cell))) 

(setc p (if (= a b) 1 0)))))) 

(def rule equality 

(let ((a-cell (the a *me*)) 

(b-cell (the b *me*)) 

(p-cel1 (the p *me*))) 

(and (node-boundp p-cell) 

(node-boundp a-cell) 

(let ((p (node-contents p-cell)) 

(a (node-contents a-cell))) 

(and (= p 1) (setc b a)))))) 

(def rule equality 

(let ((a-cell (the a *me*)) 

(b-cell (the b *me*)) 

(p-cell (the p *me*))) 

(and (node-boundp p-cell) 

(node-boundp b-cell) 

(let ((p (node-contents p-cell)) 

(b (node-contents b-cell))) 

(and (= p 1) (setc a b)))))) 

'(equality primitive)) 

Table 2-9. Expanded Definition of the equality Constraint. 


(contradiction a c) •-> (signal-contradiction *me* (list a-cell c-cell)) 

The function s ignal -cont radi ct i on causes an error, and prints information as to the source 
of the contradiction. 

The setc construct is also implemented as a LISP macro. A call to setc expands, for 
example, as: 

(setc c (+ a b)) —> (process-setc *me* 'c c-cell (+ a b)) 
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(defmacro contradiction vars 

‘(signal-con tradiction ♦me* (list ,@(forlist (v vars) (symbolconc v "-CELL"))))) 

(defun signal-contradiction (constraint cells) 

(require-constraint constraint) 

(lose "Contradiction in ~S~@[ among these pins: ~:{~S=~S~:t, 
constraint 

(forlist (cell cells) 

(requ i re-cel 1 cell) 

(list (cell-name cell) (node-contents cell))))) 

(defmacro setc (cellname value) 

‘(process-setc *me* cellname ,(symbolconc cellname "-CELL") ,value)) 

(defun process-setc (*me* name cell value) 

(require-constraint *me*) 

(require-cel 1 cel 1) 

(ctrace "~S computed the value ~S for its ~S." *me* value name) 

(== cell (constant value))) 

Table, 2-11. implementation of contradiction and setc. 


The first and third arguments to process-setc arc provided purely for the sake of the ctrace 
operation. The setting of a cell could be performed by forcibly inserting the value into the cell, 
but it is easier simply to create a constant cell containing the value and then equate it to the cell 
to be set. It is inefficient, in that an extra repository is created by constant and another by = = . 
However, it lets the existing machinery in == do all the work of checking for contradictions. (We 
will fix this inefficiency in the next chapter.) 


2.3. Sample Execution of a Constraint Program 

Here we consider an interactive session with our trivial constraint language. We shall construct 
die temperature conversion network of Figure 2-2. User input appears in lower case, and the LISP 
value produced by this input appears in uppercase, flic ctrace statements in the code produce 
comment lines beginning with “; | 

First we create instances of the constraint devices we shall need, in this case an adder and two 
multipliers. The value returned by create is the data structure for the constraint, which prints as 
the unique name of the constraint, surrounded by angle brackets (thanks to the printing code which 
appears in the definition of the constraint data type in fable 2-3). 

(create add adder) 

<ADD:ADDER-20> 

(create mult multiplier) 

<MULT:MULTIPLIER-24> 

(create othermult multiplier) 
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COTHERMULT:MULTIPLIER-28> 

The unique number (appended by the LISP function gen-name) is incremented by four each time 
because for each of these constraint instances three cells are also generated to serve as pins. We can 
refer to a pin by using the the construction. 

(the a othermult) 

<CELL-29 (A of OTHERMULT): no value) 

(the b othermult) 

<CELL-30 (B of OTHERMULT): no value> 

(the c othermult) 

<CELL-31 (C of OTHERMULT): no value> 

The ability to do this interactively is not really part of our defined constraint language; it is, 
however, a decided convenience in interacting with the system. The fact that generated names 
contain numbers in increasing order is also irrelevant to the defined computational abilities of the 
system, but do aid in understanding in what order certain actions happen to occur. Note that when 
a cell is printed, the unique name and also the pin name and owner arc printed, and also the 
value if any (the code which does this appears in fable 2-1). We did not define any input/output 
operators for our language, but the ability to examine cells interactively in this way will allow us to 
see the results of the computation. 12 

Next we declare that we will need two global variables f ahrenhe i t and cent i g rade. 

(variable fahrenheit) 

<CELL-32 (FAHRENHEIT): no value) 

(variable centigrade) 

<CELL-33 (CENTIGRADE): no value) 

Now each cell must have a repository. We can examine the repository of a cell. 

(cel 1-repository fahrenheit) 
depository for CELL-32) 

We now wire the network together. We begin by equating f ahrenhe i t to the c pin of the adder 
add. 

( = = fahrenheit (the c add)) 

DONE 


12. All of these remarks of course have little to do with the design of a constraint language as such. Rattier, they 
are intended to show how a toy system can be imbedded in a larger system (in this case a LISP system) with a 
minimum of work to gel it oil the ground just enough to exhibit a principle, without having to re-implement a host 
of trivial details (such as I/O). By arranging for the interpreter of the constraint language to be that of LISP, and 
that the forms of the constraint language are simple certain evaluable LISP forms, then when interacting with the 
system we can evaluate constraint forms or LISP forms at will. More abstractly, at any lime we may shill freely from 
language to meta-language and back. 
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Bxamination of the repository of the cell fahrenheit reveals that it has been linked to another 
cell cel 1 -23. This is the name of a cell which turns out (not very surprisingly) to be the c pin of 
adder-20, which is also called add. 

(cel 1-repository fahrenheit) 
depository for CELL-32,CELL-23> 
cell-23 

CCELL-23 (C of ADD): no value> 

(the c add) 

<CELL-23 (C of ADD): no value> 

adder-20 

<ADD:ADDER-20> 

add 

<ADD:ADDER-20> 


Specifying a constant creates a cell with no owner and name “?”. 

(constant 32) 

<CELL-34 (?): 32> 

We now connect this constant to the b pin of the adder. 13 
(== (the b add) cell-34) 

;|Awakening <ADD:ADDER-20> because its B got the value 32. 

DONE 

The ctrace statement in the definition of == (sec Fable 2-5) printed a comment indicating that 
one pin got a value and so all rules were being run. However, no rule of the adder constraint type 
can do anything with only one input. 

If we examine the b pin of add we can see that it indeed also has the value 32. 

(the b add) 

CCELL-22 (B of ADD): 32> 

Let us without further ado wire up the rest of the network of Figure 2-2. Two more ctrace 
comments arc produced when the constants 5 and 9 arc wired up. 

(== (the a add) (the a othermult)) 

DONE 

(== (the c othermult) (the c mult)) 

DONE 

(== (the b othermult) (constant 5)) 

;|Awakening <OTHERMULT:MULTIPLIER-28> because its B got the value 5. 

13. Of course, this statement is not properly part of the constraint language, but a mixture of the constraint language 
and its meta-language LISP (because the variable cel 1-34 is part of the meta-language--indeed the very fact that 
we know of the existence of that name indicates that we have gone outside the constraint language and examined 
the internals of the implementation!). 
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DONE 

( = = centigrade (the b mult)) 

DONE 

( = = (the a mult) (constant 9)) 

;|Awakening <MULT:MULTIPLIER-24> because its A got the value 9. 
DONE 


The network, now completely wired, can be used to perform a computation. Here we will try 
the computation of Figure 2-3. The cell centigrade is equated to the constant—40. 

(== centigrade (constant -40)) 

;(Awakening <MULT:MULTI PLIER-24> because its B got the value -40. 

; | <MULT :MULTIPL.IER-24> computed the value -360 for its C. 

;|Awaken i ng <OTHERMULT:MULTIPLIER~28> because its C got the value -360. 

;|<OTHERMULT:MULTIPLIER-28> computed the value -72 for its A. 

;|Awakening <ADD: ADDER-20> because its A got the value -72. 

;|<ADD:ADDER-20> computed the value -40 for its C. 

;(Awakening <ADD:ADDER-20> because its C got the value -40. 

;(<ADD:ADDER-20> computed the value -72 for its A. 

; (<ADD: ADDF.R-20> computed the value 32 for its B. 

;|<ADD:ADDER-20> computed the value -40 for its C. 

;(Awakening COTHERMULT:MULTIPLIER-28> because its A got the value -72. 

;j <0THERMULT:MULTIPLIER-28> computed the value -72 for its A. 

;|<0THERMULT:MULTIPLIER-28> computed the value 5 for its B. 

;|<OTHERMULT:MULTIPLIER-28> computed the value -360 for its C. 

;|<OTHERMULT:MULTIPLIER-28> computed the value 5 for its B. 

;j<OTHERMULT:MULTIPLIER-28> computed the value -360 for its C. 

;(Awakening <MULT:MULTIPLIER-24> because its C got the value -360. 

;|<MULT:MULTIPLIER-24> computed the value 9 for its A. 

;|<MULT:MULTIPLIER-24> computed the value -40 for its B. 

;|<MULT:MULTIPLIER-24> computed the value -360 for its C. 

DONE 


Note that each constraint device here has computed new values for its pins, including those pins 
which originally provided input values! For example, given a and c the adder computed a value 
for b—but once b was in hand, it could be used with a to compute c, and with c to compute 
a. Nothing detects the fact that the adder itself computed the value for b. On the other hand, the 
process docs not iterate indefinitely (a common bug indeed when implementing this sort of thing!) 
because == does not run any rules when a value is equated to a cell which already has a value 
(because then tine set of newcomers is empty). 

If we now examine the cell f ah renhe i t, we see that indeed it has acquired the value —40. 
fahrenheit 

<CELL-32 (FAHRENHEIT): -40> 
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Fic;urI'2-8. Operation of the maxer Constraint. 


Suppose now that we attempt to set fahrenheit to 32. When merge-values gets the 
values —40 and 32, it finds that they arc incompatible, and invokes 1 ose. 

(== fahrenheit (constant 32)) 

>>ERR0R: Contradiction between <CELL-32 (FAHRENHEIT): -40> 
and <CELL-51 (?): 32>. 

As another toy example to show off die contradict ion mechanism, consider a maxer 
box with its a pin equated to 5. We w ill take three such boxes and equate their c pins to 7, 5, and 
3, respectively. 

(create ml maxer) 

<M1:MAXER-68> 

(create m2 maxer) 

<M2:MAXER-72> 

(create m3 maxer) 

<M3:MAXER-76> 


(== (the a ml) (constant 5)) 

;|Awakening <M1:MAXER-68> because its A got the value 5. 

DONE 

(== (the a m2) (constant 5)) 

;|Awakening <M2:MAXER-72> because its A got the value 5. 

DONE 

(== (the a m3) (constant 5)) 

;|Awakening <M3:MAXER-76> because its A got the value 5. 

DONE 

From the values a — 5 and c — 7, ml can deduce 6 = 7. (See Figure 2-8a.) 
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(== (the c ml) (constant 7)) 

;|Awakening <M1:MAXER-68> because its C got the value 7. 

;|<M1:MAXER-68> computed the value 7 for its B. 

;|Awakening <M1:MAXER-68> because its B got the value 7. 

;|<M1:MAXER-68> computed the value 7 for its B. 

;|<M1:MAXER-68> computed the value 7 for its C. 

;|<M1:MAXER-68> computed the value 7 for its C. 

DONE 

Note that values were computed for b and c twice each. This is because in this implementation 
when a value is received on any pin, all rules are fired. Since two pins got values, all rules are fired 
twice. It all settles down in the end, but is a source of inefficiency. 

When a = 5 and c — 5, no specific value can be computed for b. All that is known is that 
b < 5. (See Figure 2-8b.) 

(== (the c m2) (constant 5)) 

;(Awakening <M2:MAXER-72> because its C got the value 5. 

DONE 

When a = 5 and c — 3, we have an inconsistent situation. (See Figure 2-8c.) 

(== (the c m3) (constant 3)) 

;|Awakening <M3:MAXER-76> because its C got the value 3. 

>>ERR0R: Contradiction in <M3:MAXER-76> among these pins: A=5, C=3. 

The inconsistency has caused a fatal error. (Later we will sec how such errors can be useful 
rather than fatal, and can cause the system to search for ways to resolve the problem.) 


2.4. A Difficulty with Division 

There is an intentional peculiarity in our definition of the multiplier primitive in Table 2- 
7, which is that if a division does not come out exactly it simply fails to compute a result. One might 
argue that since we have defined the data objects of our language to be the integers, then it is an 
error to try to divide, say, 7 by 3, because there is no object n such that 3 X n = 7. 

Suppose that we construct another temperature conversion network as in §2.3, just before 
we assign the value —40 the cent igrade. Let us see what happens if we instead equate 
cent ig rade to the constant 37. 

(== centigrade (constant 37)) 

;|Awakening <MULT:MULTIPLIER-100> because its B got the value 37. 

;|<MULT:MULTIPLIER-100> computed the value 333 for its C. 

;|Awakening <OTHERMULT:MULTIPLIER-104> because its C got the value 333. 

;(Awakening <MULT:MULTIPLIER-100> because its C got the value 333. 
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Figukh 2-9. A Temperature Conversion Which "Failed". 


;|<MULT:MULTIPLIER-100> computed the value 9 for its A. 

;|<MULT:MULTIPLIER-100> computed the value 37 for its B. 

;|<MULT:MULTIPLIER-100> computed the value 333 for its C. 

DONE 

It seems that mult performed some useful work, but othermult did not, and add was not 
even awakened. (Sec Figure 2-9.) 

f ahrenhei t 

<CELL-108 (FAHRENHEIT): no value> 

Indeed fahrenheit has not had any value computed for it. 

(the a othermult) 

<CELL-105 (A of OTHERMULT): no value> 

(the b othermult) 

<CELL-106 (B of OTHERMULT): 5> 

(the c othermult) 

<CELL-107 (C of OTHERMULT): 333> 

The constraint othermult has values for b and c , but cannot compute a value for a because 
the division 333/5 is not exact. However, we do find it useful in mathematics to extend the 
integers to the rational numbers, and say that there is an object which represents the result of this 
devision, even though we don’t have any better way to represent it than as “333/5”, that is to 
say, “that object which is the quotient of 333 and 5”. If we examine the state of the network in 
Figure 2-9, we can sec that this quotient is represented by the network itself .’ considered as a data 
structure. Moreover, the network represents the fact that fahrenheit is the difference between 
this quotient (whatever it is) and 32. 
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FiGURi: 2-10. Constraining Three Points to be Fqiuilly Spaced (i). 


Wc could introduce rational numbers as a primitive data type. Such an implementation would 
presumably use a MSP data structure to hold the numerator and denominator of a rational number, 
and provide LISP functions for manipulating such data objects, providing primitives for rational 
arithmetic. This would be a strange move at this point, however, as the data structure merely copies 
what the constraint network represents anyway: a data structure (the multiplier constraint, con¬ 
sidered as a division box) with two known values (numerator and denominator). The term “rational 
arithmetic” is a misnomer, for it is actually a curious combination of arithmetic and algebra—and 
thus far our language, which can propagate values within the network but cannot augment the 
network, encompasses only arithmetic. 

There is one more way in which local propagation can fail to compute a result. If a constraint 
network contains cycles, then propagation may not be able to make progress. The difficulty is 
that such a network expresses a set of simultaneous equations which must be solved by algebra. 
Consider the network in Figure 2-10. There arc three variables pi, p2, and p3, intended to 
represent the positions of three points along an axis. The network constrains the three points to 
be equally spaced; that is, p2 is midway between pi and p3. The network actually expresses the 
first description of the last sentence more closely; the two adder constraints determine the spacing 
between adjacent points, and then the two distances are equated. 

p2 — pi = p3 — p2 

The second description corresponds more to die formula 

p2 = 

Yet a third formulation is that the spacing between the endpoints is twice the spacing between 
either set of adjacent points. 
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Figure 2-12. A Redundant Network for Fqually Spacing Three Points. 


However, the network expresses only the first formulation. Given either pair of adjacent points, the 
position of the third is easily computed: one adder calculates the spacing between them, then the 
other adds or subtracts this spacing from the midpoint to locate the endpoint not given. However, if 
the two endpoints arc given and not the midpoint, neither adder can compute anything. 

Similarly, if we were to use just one version of the third formulation (see Figure 2-11), then 
given pi and p2 it would not be possible to compute p3 by local propagation. 

One way to enable any point to be computed given the other two is to use a redundant net¬ 
work expressing multiple ways of viewing the problem [Sussman 1977] (sec Figure 2-12). Another 
way is simply to use an entirely different network, such as the second formulation above (see 
Figure 2-13); however, deriving this from the first network requires some non-trivial algebra, and 
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indeed a new concept: the other networks express direct spacing requirements, whereas Figure 2-13 
uses the concept of “averaging the positions of die endpoints”. 


2.5. Summary of the Trivial Constraint Language 

Our little language illustrates the principle of computation by local propagation, with the 

direction of propagation determined dynamically as needed. It certainly leaves much to be desired: 

• The data objects are limited to the integers. We are used to having other kinds of objects in 
programming languages, including compound objects such as arrays. 

• There is no abstraction capability: the language is “flat”, which is to say that we can build very 
large networks but cannot in any way encapsulate portions into modules. We would like to have 
something analogous to subroutines. 

• A given network can be built and then used once, but then must be thrown away. For example, 
in §2.3, after using a temperature conversion network to convert —40° C to —40° F, we could 
not then use the same network to convert 37° C—we got a contradiction because the network 
was already “used up”. This means we cannot use a constraint network in a dynamic manner 
to track a changing input—and this would be one of the most useful attributes of a constraint 
language, if we could only implement it. 

• flic mechanism of local propagation can fail to compute a result for any of several reasons. 
A relationship may be multiple-valued (as arernax* z), and there is no good way to choose 
among the possibilities. A relationship may “have a value”, but one which is not really in the 
domain of the language (for example, rational numbers in a system providing only integers). 
These are both local properties of a single constraint. It is also possible that the difficulty is 
global, involving cycles in the network, and cannot be handled by a local technique. This can be 
handled by algebraic techniques, which involve transformations of the network, which for now 
is outside die computational scope of our system. 
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• When contradictions occur (for whatever reason—re-use of a network, a mistake, etc.) there 
is presently no easy way to determine why the contradiction occurred. We know what the 
difficulty is locally (for example, division by zero), but we do not know the global causes. A 
related difficulty is that when something foils to be computed, as in §2.4, we don’t know why 
that happened cither. 

• The system is computationally inefficient. It often recomputes the same value many times. 

We will deal with all these difficulties in one way or another. To deal with all at once would 
introduce overwhelming complexity of detail; therefore we shall examine each feature separately 
before combining them. 



The best of the worst is full alive, 

Tho' worst is not at first — 

No livery may deliver me 
An aliver liverwurst. 

—Wall Kelly (1952) 

/ Go Togo 
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W lll-N A DECISION is made, wc very often wish to ask the person who made it not only, 
“What is the result?”, but also, “Why is that so? Why didn’t you choose something else? 
What factors went into your decision?” This is particularly true of design decisions in engineering. 
There arc several reasons for asking such questions. If the result is not obvious, or by itself doesn’t 
carry enough information, then the structure of the process which derived it may shed more light. 
If something goes wrong later, wc need this information to determine how to fix the problem; we 
need to know what can be changed without affecting the result, or what to change to change the 
result. More generally, if several decisions have been made, and one must be altered, one can do 
this with minimum effort if one can determine parameters of the decision which will not affect 
others. Another possibility is that no decision was reached. In this case one wants to know why, and 
what additional facts arc needed to make a decision. 

Now all of this is especially true of computers, which make so many decisions and computa¬ 
tions so rapidly that it is very difficult to determine what happened (or didn’t happen) after the fact, 
flic entire art of analyzing post-mortem core dumps is devoted to answering the questions outlined 
above, flic notion of an audit trail (computerized or not) is also intended to permit the reconstruc¬ 
tion of the computational process. It would be much simpler if programs were to keep track of the 
reasons for their computations from the start. Such programs could be held accountable for their 
actions, and required to explain themselves on request. 

In this chapter we will alter the system of Chapter Two to record the history of the computa¬ 
tion as propagation occurs, facilities will be developed for extracting this history from the network 
in a useful form. 
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3.1. Responsible Programs 

It is not at all difficult to augment our trivial constraint system to record reasons for each 
computational action. We call such reasons dependencies , because they indicate for each quantity 
on what other quantities its derivation depends. 


3.1.1. Dependency Information Can Be Used to Explain Computations 

Let us suppose that we have been given a temperature conversion network with which we are 
unfamiliar, but we have been assured that it correctly constrains two variables called fall renheit 
and centigrade. We equate centigrade to —40, then ask for the value of fah renhe it , 
and arc told that it also is —40. 

f ahrenheit 

<CELL-35 (FAHRENHEIT): -40> 


We don’t trust the calculation (perhaps we suspect that there is a “short circuit” between the 
fahrenheit and cent igrade variables—people sometimes make that sort of mistake!). We 
ask why fahrenheit is—40. 

(why fahrenheit) 

:The value -40 is in CELL-35 because that is connected to (THE C ADD), 

; and <ADD:ADDER~23> computed it using rule ADDER-RULE-1 
; from: CELL-24 (A) = -72, CELL-25 (B) = 32. 

Q.E.D. 

So the adder add computed —40 from —72 and 32. Let us investigate further. 

(why (the b add)) 

;The value 32 is in CELL-25 because that is connected to CELL-37, 

; and that is a constant. 

Q.E.D. 

(why (the a add)) 

:The value -72 is in CELL-24 because that is connected to (THE A OTHERMULT), 
; and <OTHERMULT :MULTIPLIER-31> computed it using rule MIJLTIPLIER-RULE-8 
; from: CELL-33 (B) = 5, CELL-34 (C) = -360. 

Q.E.D. 

One value is a constant, and the other was computed by a multiplier called othermul t. Let us 
examine this multiplier. 


(why (the b othermult)) 





70 


Chap i i:r Three 


DEPENDENCIES 


;The value 5 is in CELL-33 because that is connected to CELL-38, 

; and that is a constant. 

Q.E.D. 

(why (the c othermult)) 

;The value -360 is in CELL-34 because that is connected to (THE C MULT), 

; and <MULT:MULTIPLIER-27> computed it using rule MULTIPLIER-RULE-6 
; from: CELL-28 (A) = 9, CELL-29 (B) = -40. 

Q.E.D. 

Now othermult got its c value from another multiplier called mult. We press on ... 

(why (the a mult)) 

;The value 9 is in CELL-28 because that is connected to CELL-39, 

; and that is a constant. 

Q.E.D. 

(why (the b mult)) 

:The value -40 is in CELL-29 because that is connected to CELL-40, 

; and that is a constant. 

Q.E.D. 

We have now traced out the entire computation, and if we reconstruct the flow of information, we 
can deduce that the structure of the computation can be expressed as the formula 

, . ... 9 X —40 

fahrenheit =---|- 32 

5 

which is certainly the correct computation. 

We could also inquire as to the status of centigrade (for example, we might have forgotten 
that we set it ourselves 1 ). 

(why centigrade) 

; The value -40 is in CELL-36 because that is connected to CELL-40, 

; and that is a constant. 

Q.E.D. 

(why cell-40) 

;The value -40 is in CELL-40 because that is a constant. 

Q.E.D. 

Now perhaps we don’t care about the form of the computation, but only wish to know what 
input parameters were used to compute the result. ( This is trivial for our example, but for very 
complicated networks this may not be at all obvious.) 

(why-ultimately fahrenheit) 

:The value -40 is in CELL-35 because that is connected to (THE C ADD), 


1. In general, we reserve the right to have a poor memory—the computer, however, is supposed to remember! Poor 
computer. 
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; and it was ultimately derived from: 

; <CELL-37 (?): 32>, 

; <CELL-40 (?): -40> = CENTIGRADE, 

; <CELL-39 (?): 9>, 

; <CELL-38 (?): 5>. 

Q.E.D. 

Four values went into the computation, one of which has the name centigrade. Indeed, if 
names were given to the other values, we would like to sec them also. 

(variable linear-offset) 

<CELL-41 (LINEAR-OFFSET): no value> 

(variable 1 inear-scale-factor-denominator) 

<CELL-42 (LINEAR-SCALE-FACTOR-DENOMINATOR): no value> 

(variable 1 i near-seale-f actor-numerator) 

<CELL-43 (LINEAR-SCALE-FACTOR-NUMERATOR): no value> 

(variable another-name) 

<CELL-44 (ANOTHER-NAME): no value> 

(== (the b add) linear-offset) 

DONE 

(== (the b othermult) linear-scale-factor-denominator) 

DONE 

(== (the a mult) 1inear-scale-factor-numerator) 

DONE 

(== centigrade another-name) 

DONE 

(why-ultimately fahrenheit) 

:The value -40 is in CELL-35 because that is connected to (THE C ADD), 

; and it was ultimately derived from: 

; <CELL-37 (?): 32> == LINEAR-OFFSET, 

; <CELL-40 (?): -40> == CENTIGRADE == ANOTHER-NAME, 

; <CELL-39 (?): 9> = = LINEAR-SCALE-FACTOR-NUMERATOR, 

; <CELL-38 (?): 5> == LINEAR-SCALE-FACTOR-DENOMINATOR. 

Q.E.D. 


Wc can of course use the two query types together. After using why to trace down the 
computation tree a few steps, wc can use why-ul timately to determine which parameters an 
intermediate value depends on. 

(why-ultiniately (the c mult)) 

;The value -360 is in CELL-30 because it was ultimately derived from: 

; <CELL-40 (?): -40> == CENTIGRADE == ANOTHER-NAME, 

; CCELL-39 (?): 9> == LINEAR-SCALE-FACTOR-NUMERATOR. 

Q.E.D. 
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3.1.2. Required Parameters Can Be Deduced from the Network Structure 

Dependency information indicates how information was propagated within the network; the 
information exists only after computations have been performed. Because any computation per¬ 
formed by local propagation follows the structure of the network (having choices only in the 
direction of the (low over existing paths), however, we can consider the network to prescribe the set 
of potential dependency relationships. Hence the network structure can be used to explain why a 
computation did not occur, or to indicate how one could occur which has not yet. 

Let us take another temperature conversion network, as at the beginning of §2.4. Before 
assigning any value to centigrade, let us ask “(why fahrenhei t)'\ this time meaning “Why 
docs fahrenheit not have a value?” 

f ah renhei t 

<CELL-108 (FAHRENHEIT): no value> 

(why fahrenheit) 

;CELL-108 has no value. I could compute it 
; from pins A, B of ADD by rule ADDER-RULE-1. 

Q.E.D. 

This tells us that fahrenheit has no value, and suggests a way in which it might be computed, 

(why centigrade) 

;CELL-109 has no value. I could compute it 
; from pins A, C of MULT by rule MULTIPLIER-RULE-7. 

Q.E.D. 

Of course centigrade has no value either. It could be computed if fahrenheit were given, 
for example. 

(why-ultimately fahrenheit) 

;CELL-108 has no value. Perhaps knowing the value of CENTIGRADE would help 
Q.E.D. 

(why-ultimately centigrade) 

;CELL-109 has no value. Perhaps knowing the value of FAHRENHEIT would help 
Q.E.D. 

Ultimately the computation of cither variable depends on the other plus the existing constants (5, 
9, and 32) in the network. Only missing parameters are given by why-ul timately. 

(why (the c mult)) 

;CELL-103 has no value. I could compute it 
; from pins A, B of OTHERMULT by rule MULTIPLIER-RULE-6; or 
; from pin B of OTHERMULT by rule MULTIPLIER-RULE-5; or 

; from pin A of OTHERMULT by rule MULTIPLIER-RULE-4; or 

; from pins A, B of MULT by rule MULTIPLIER-RULE-6; or 
; from pin B of MULT by rule MULTIPLIER-RULE-5; or 
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; from pin A of MULT by rule MULTIPLIER-RULE-4. 

Q.E.D. 

The intermediate point (the c mult) could be computed in any of a number of ways, by either 
of two constraint devices. 

(why-ultimately (the c mult)) 

;CELL-103 has no value. Perhaps knowing the value of CENTIGRADE or 
; FAHRENHEIT would help. 

Q.E.D. 

Ultimately either of the two variables could be used to compute a value for (the c mult). 

Suppose now that we equate centigrade to 37 as in §2.4. As before, othermul t will be 
unable to compute a value because the division is not exact. 

( = = centigrade (constant 37)) 

; (Awakening <MULT:MULTIPLIER-100> because its B got the value 37. 

;|<MULT:MULT IPLIER-100> computed 333 for its part C from pins A, B. 

; |Awakening <0THERMULT:MULTIPLIER-104> because its C got the value 333. 

; |Awakening <MULT:MULTIPLIER-100> because its C got the value 333. 

DONE 

Therefore fahrenheit has no value, 
f ahrenheit 

<CELL-108 (FAHRENHEIT): no value> 

(why fahrenheit) 

:CELL-108 has no value. I could compute it 
; from pins A, B of ADD by rule ADDER-RULE-1. 

Q.E.D. 

(why-ultimately fahrenheit) 

;CELL-108 has no value. 

Q.E.D. 

A sad state of affairs indeed. About all can be said is that the computation has failed. There arc 
no missing parameters—centigrade has been supplied, 'flic computation has broken down at 
othermul t. 

(why (the a othermult)) 

;CELL-105 has no value. I could compute it 
; from pins B, C of ADD by rule ADDER-RULE-3; or 

; from pins B, C of OTHERMULT by rule MULTIPLIER-RULE-8. 

Q.E.D. 

(the b othermult) 

<CELL-106 (B of OTHERMULT): 5> 

(the c othermult) 

CCELL-107 (C of OTHERMULT): 333> 
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(Assume that the multiplication happens to be performed last.) 
Figure 3-1. Multiple Suppliers in the Fqual-Spacing Network. 


1 he only rule othermul t has for computing its a is multi pi ier-rule-8, which requires b 
and c. However, the b and c do have values, and nevertheless no value was computed for the 
a. So there is no hope. Also, it would not do for (why-ultimately fahrenheit) to say, 
“Perhaps knowing the value of ( the a othermul t) would help”; there is no integer value that 
can be given it that is consistent with the other pins of ot he rmu 11 already known. 

We will return to this problem of ‘Tailed computations” in a later section. First let us discuss 
how to implement the recording of dependencies, and the mechanisms needed for the operation of 
why and why-ultimately. 


3.2. Recording Dependencies 

Recording dependency information simply amounts to remembering the directions of the ar¬ 
rows of Figure 2-3 (page 41), plus which rule was used to compute each outgoing value from a 
constraint box. Observe that a repository which has a value can have first acquired that value from 
exactly one of its associated cells (a constant, or a pin of a constraint). We refer to this cell as the 
supplier of the value. Later other cells may also provide values, but such values will merely confirm 
or contradict the first value. 2 

It is possible to regard other cells which provide values as subsidiary suppliers, and to 
record them along with the distinguished supplier. There are difficulties with using subsidiary 
suppliers, however. Recall that in §2.3 the adder add computed b from a and c, and so the 


2. This argument implicitly assumes a sequential interpreter for the language such as we have presented here. ITie 
language certainly admits parallel evaluation, however, in which case computed values may arrive at a repository 
“simultaneously”. In this case we assume that an arbiter chooses one to be first. 
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(deftype repository ((rep-contents ()) (rep-boundp ()) (rep-cells ()) 

] (rep-supplier ()) (rep-rule ()) (rep-mark ())) 

(format stream "<Repos i tory~:: ~S~]~@[ for ~{~S~t 
(rep-boundp repository) 

(rep-contents repository) 

(cell-ids repository))) 

(defmacro node-contents (cell) 1 (rep-contents (cell-repository ,cell))) 
(defmacro node-boundp (cell) ‘(rep-boundp (cel 1-repository ,cell))) 
(defmacro node-cells (cell) ‘(rep-cells (cel 1-repos i tory ,cell))) 

|(defmacro node-supplier (cell) ‘(rep-supplier (cel 1-repository ,cell))) 
j(defmacro node-rule (cell) ‘(rep-rule (cel 1-repository , c e11 ))) 
[(defmacro node-mark (cell) ‘(rep-mark (cel 1-repository ,cell))) 

Compare (his with Table 2-1 (page 45). 

Tablf. 3-1. Extra Repository Fields for Recording Dependencies. 


cell (the b add) served as supplier for its repository. However, the adder then proceeded to 
awaken to the fact that its b had just received a value, and computed c from a and b (and 
similarly a from c and b). Thus ( the c add) became a subsidiary supplier for its repository. 
To make use of this fact, however, in explaining the computation of (the b add) would involve 
circular reasoning. While we might circumvent this particular problem by avoiding the awakening 
of the adder when it computed a value for its own pin, the problem would remain in general in 
networks with large cycles. For example, in the equal-spacing network of Figure 2-12 (page 65), 
the propagation of values might proceed as in Figure 3-1, and the multiplier would be a subsidiary 
supplier of the spacing factor. However, we would not want to use this fact to justify the computa¬ 
tion of the spacing factor, because then the value of p3 would appear to to have been computed 
indirectly from itself. 

In order not to produce circular explanations, it is necessary for the dependency structures to 
be well-founded. We will achieve this be recording only primary suppliers, which guarantees that 
no cycles will occur. (One can think of information as a fluid spreading from constants throughout 
the constraint network by propagation, different flows combining within constraint boxes, but 
stopping short just before meeting in a repository.) 

In the implementation we therefore introduce some new components for repositories. (It will 
not be necessary to change the definitions for cells, constraints, or constraint-types.) These arc: 

• A supplier , which is that cell among the node-cells which first provided the value for the 
repository. The supplier is null if the repository has no value (boundp is false). 

• A rule, which is the name of the rule used to compute the value. The rule component is null if 
the repository has no value, or if the supplier has no owner (i.c., is a constant). 

• A mark, which is normally null but is available to serve as a mark bit or a counter by various 
graph-marking algorithms to be intoduccd later. 
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(defun constant (value) 

(let ((cell (gen-cell))) 

(setf (node-contents cell) value) 

(self (node-boundp cell) t) 

(setf (node-supplier cell) cell) 
cell)) 

Compare this with Table 2-2 (page 47). 

Table: 3-2. A Constant Cell Is Its Own Supplier. 


The new definition of the repository data structure appears in Table 3-1. Vertical lines to the 
left of the code draw attention to differences from the previous version. As before, extra macros 
like node-suppl ier arc defined to make it easier to refer to components of a node (in the 
repository) given one of its cells. 

New code is needed to maintain the supplier and rule components of repositories. No new 
code is needed for generating a cell (gen-cell); the initial-value mechanism of deftype cor¬ 
rectly initializes the new components of a repository. When a constant cell is created, however, that 
cell should be its own supplier (see Table 3-2). 

Several changes to the code for == appear in fable 3-3. One improvement which is 
superficially unrelated to maintaining dependencies is that no new repository is created when two 
cells arc equated; instead one repository is re-used. Whichever repository has a value is the one 
chosen, so it is unnecessary to explicitly update the supplier and rule components. Also, it is 
only necessary to update (in die dolist loop) the cel 1 - repos i tory components of cells 
which belonged to the repository not chosen. The loop for awakening all the owners of a set of 
cells has been abstracted out as a separate procedure awaken-al 1, which will also be used by 
process-setc later. 

A particularly nasty opportunity for implementation bugs arises in the situation where both 
die cells being equated already have values. As before, merge-values will ensure that the two 
values are compatible. However, it previously did not matter which of two compatible values 
was used; but now, when values have dependency information attached, it is crucial not to pick 
the wrong one, lest circularities arise in the dependency structure. Suppose, for example, that a 
multiplier m is created, and its a is equated to zero. 

(create m multiplier) 

<M:MULTIPLIER-23> 

(== (the a m) (constant 0)) 

;(Awakening <M:MULTIPLIER-23> because its A got the value 0. 

;|<M:MULTIPLIER-23> computed 0 for its part C from pin A. 

;|Awakening <M:MULTIPLIER-23> because its C got the value 0. 

DONE 
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(defun == (cel 11 cel 12) 

(require-cel 1 cellt) 

(require-cel 1 ce!12) 

{or (eq (cel 1-repository celll) {cel 1-repository cel 12)) 

(let ((rl (cell-repository celll)) 

(r2 {cel 1 - repository cel!2)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp cel 12))) 

(let ((r (if (or (not cb2) (and cbl (ancestor celll ce112))) rl r2)) 
(rcells (append (rep-cells rl) (rep-cells r2)))) 

(setf (rep-contents r) (merge-values celll ce112)) 

(let ((newcomers (if cbl (if cb2 '() (rep-cells r2)) 

(if cb2 (rep-cells rl) '())))) 

(setf (rep-cells r) rcells) 

(dolist (cell (rep-cells (if (eq r rl) r2 rl))) 

(setf (cel 1-repository cell) r)) 

(awaken-all newcomers) 

'done))))) 

(defun awaken-all (cells) 

(dolist (cell cells) 

(require-cel 1 cell) 

(cond ((cell-owner cell) 

(ctrace "Awakening ~S because its ~S got the value ~S." 

(cell-owner cel 1) 

(cell-name cel 1) 

(node-contents cell)) 

(awaken (cell-owner cell)))))) 

Compare this with Table 2-5 (page 51). 

Table: 3-3. Maintaining Supplier Components When F.quating Cells. 


Now that the a and c both have the value zero, they arc equated. 

(== (the c m) (the a m)) 

DONE 

(why (the a m)) 

;The value 0 is in CELL-24 because that is connected to (THE C M), 

; and <M:MULTIPLIER-23> computed it using rule MULTIPLIER-RULE-4 
; from: CELL-24 (A) = 0. 

Q.E,D. 

This is what occurs if the version of == in fable 3-4 is used (which is a version the author used for 
quite a while before finding the bug while trying to “prove” it correct to himself!). The repository 
belonging to c is arbitrarily chosen for use by the two cells for a and c, and the result is that c 
appears to be the primary supplier rather than the constant zero. Now zero is not the only value 
consistent with the network constructed (a and c could be any value if b were 1), and so it is 
quite improper for the value zero in ( the a m) to claim to support itself. 

That this dependency cycle arises in this example is of course accidental. 1 lad the equating of 
a and c been written as 
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(defun == (celll cell2) 

(require-cel 1 celll) 

(requ ire-cel 1 cell2) 

(or (eq (cell - repository celll) (cel 1-repository cell2)) 

(let ((rl (cel 1 - repository celll)) 

(r2 (cel 1-repos i tory ce112)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp cell2))) 

(let ((r (if cbl rl r2)) ;There is a bug here! 

(rcells (append (rep-cells rl) (rep-cells r2)))) 

(setf (rep-contents r) (merge-values celll cell2)) 

(let ((newcomers (if cbl (if cb2 '() (rep-cells r2)) 

(if cb2 (rep-cells rl) '())))) 

(setf (rep-cells r) rcells) 

(dolist (cell (rep-cells (if (eq r rl) r2 rl))) 

(setf (cel 1-repository cell) r)) 

(awaken-all newcomers) 

'done))))) 

Compare this with Table 3-3. 

Table 3-4. An Incorrect Implementation of Equating. 


(== (the a m) (the c m)) 

then the correct repository would have been accidentally chosen, and all would be well. Again, if 
the connection between a and c been made before the connection to the constant zero, then all 
would have been well. However, we would like a constraint language to be as free as possible of 
such accidental ordering problems. The system must always do things in a consistent and correct 
manner. This is the reason for the use of the ancestor predicate in the (correct) definition of 
= = in Table 3-3. Given two cells which have values, ancestor returns “true” if and only if the 
value in the second cell was supplied by a computation depending in part on the first cell; in this 
case the first cell is said to be an ancestor of the second. This predicate defines a partial order on 
cells with values if the dependencies arc kept consistent and cycle-free; indeed, the predicate is 
precisely that partial order defined by the transitive closure of the “primary supplier” relation plus 
the “triggers-for” relation which indicates what values were used by a rule to compute a new value. 
The definition of ancestor will appear a little later when details of the new representation of 
rules have been elaborated upon. 

In the last chapter rules were simply lisp functions which could be run whenever a cell got 
a value. This will still be true, but for explanation purposes it will be useful to associate other 
information with rules. As a matter of implementation convenience 3 the property list of the symbol 
naming the rule is used to stoic this extra information. It would be perfectly reasonable to define 

3. or laziness—but this illustrates a common technique of LISP programming: the use of the property list. It also 
illustrates a general technique of interactive programming: do as little work as you can while trying out an idea— 
the time to polish the code is after the idea is known to work. Put another way, it’s not worth investing a lot of 
effort for the sake of elegance or speed in an idea that may not work anyway. 
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(defprim adder (a b c) 

(c (a b) (setc c (+ a b))) 

(b (a c) (setc b (- c a))) 

(a (b c) (setc a (- c b)))) 

(defprini multiplier (a b c) 

(c (a) (and (zerop a) (setc c 0))) 

(c (b) (and (zerop b) (setc c 0))) 

(c (a b) (setc c (* a b))) 

(b (a c) (and (not (zerop a)) (zerop (\ c a)) (setc b (// c a)))) 

(a (b c) (and (not (zerop b)) (zerop (\ c b)) (setc a (// c b))))) 

(defprim maxer (a b c) 

| (c (a b) (setc c (max a b))) 

(b (a c) (cond ((< a c) (setc b c)) 

((> a c) (contradiction a c)))) 

| (a (b c) (cond ((< b c) (setc a c)) 

((> b c) (contradiction b c))))) 

(defprim minner (a b c) 

(c (a b) (setc c (min a b))) 

(b (a c) (cond ((> a c) (setc b c)) 

((< a c) (contradiction a c)))) 

J (a (b c) (cond ((> b c) (setc a c)) 

((< b c) (contradiction b c))))) 

(defprim equality (p a b) 

((p) (or (= p 0) (= p 1) (contradiction p))) 

(p (a b) (setc p (if (= a b) 1 0))) 

(b (p a) (and (= p 1) (setc b a))) 

(a (p b) (and {= p 1) (setc a b)))) 

(defprim gate (p a b) 

((P) ( or ( = P 0) (= P 1) (contradiction p))) 

(p (a b) (or (= a b) (setc p 0))) 

(b (p a) (and (= p 1) (setc b a))) 

(a (p b) (and (= p 1) (setc a b)))) 

Compare this with Table 2-7 (page 53). 

Tahiti 3*5. Implementation of Primitive Constraints with Dependency Information. 


a new data type called rule with several components (one of them being the function itself), 
but this technique lessens the distance between the old and new code; for example, the code for 
awaken need not be altered. 

With each rule is associated two lists of names of pins. The list trigger-names contains the 
names of pins which must have values in order to run the body of the rule. This is exactly the set 
of pins whose boundp components are checked by the preamble in each rule defined by defprim. 
The list output-names contains the names of pins which might (or might not) receive values when 
the rule is run. Thus these arc the pins which arc “inputs” or “outputs” for that rule. Any given 
invocation of the rule might not use all the inputs and might not give values to all the outputs, 
however, depending on the values of inputs examined. 
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|(defmacro defrule (typenaine output-names trigger-names . body) 

(let ((rulename (gen-name typename 'rule))) 

‘(progn 'compile 

(push ',rulename (ctype-rules ,typename)) 

(defun ,rulename (*me*) (let ((*rule* ',rulename)) ,@body)) 
(defprop ,rulename ,trigger-names trigger-names) 

(defprop ,rulename ,output-names output-names) 

'(,typename rule)))) 

(defmacro defprim (name vars . rules) 

‘(progn 'compile 

(declare (special ,name)) 

(setq ,name (make-constraint-type)) 

(setf (ctype-name ,name) ',name) 

(setf (ctype-vars ,name) ',vars) 

,@(forlist (rule rules) 

(do ((r rule (cdr r)) 

(output-names '() (cons (car r) output-names))) 

((or (null (car r)) (not (atom (car r)))) 

(let ((trigger-names (car r)) 

(body (cdr r))) 

‘(defrule ,name ,output-names ,trigger-names 
(let ,(forlist (var vars) 

‘(,(symbolconc var "-CELL") (the ,var *me*))) 
(and ,@(forlist (var trigger-names) 

‘(node-boundp ,(symbolconc var "-CELL"))) 
(let ,(forlist (var trigger-names) 

‘(,var (node-contents 

,(symbol cone var "-CELL")))) 

,@body)))))))) 

'(,name primitive))) 

Compare this with Table 2-8 (page 55). 

Table: 3-6. Definition of defprim Which Saves Rule Information. 


These lists could be computed automatically by analyzing the code of die rule-body, and a 
“real” constraint language system ought to do this. To save work here, however, that information 
will be represented redundantly (just as in the last chapter the set of trigger names was written 
redunadantly). flic format of defprim is redefined such that the output names arc written before 
the list of input names in each rule clause. New definitions of the primitive constraint boxes are 
in 'fable 3-5; new definitions of de fprim and defrule appear in Table 3-6. (Only the most im¬ 
portant changes in die code arc indicated by vertical lines to the left—for example, the substitutions 
of “trigger-names” for “(car rule)” in several places in defprim are not marked.) One 
change to defrule which is used by process-setc is that the variable *rule* is bound to 
the name of the rule when the rule-body is executed. 

If the primary supplier for a value is a pin of a constraint, then the repository for that value 
also contains the name of the rule which derived that value. Given that, the names of the triggers 
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(defun 

ances 

tor (cel 11 cel 12 

) 




(let 

((rl 

(cel 1-repository 

cel 11)) 





(r2 

(cell-repository 

cel 12))) 




(or 

(eq 

rl r2) 






(and 

(rep-boundp r2) 







(cell-owner (rep-supplier 

r2)) 





(do ((tns (get 

(node-rule 

(rep-supplier 

r2)) 

' trigger-names) 



(edr 

tns))) 






((null tns) 

0) 






(and (ancesto 

r celll (*the (car tns) 

(cell 

-owner (rep-supplier r2)))) 



(return 

t))))))) 





Tabu- 3-7. Definition 

of the Ancestor Relationship 

i between Cells with Values. 


for that rule can be obtained, and from that and the owner of the pin the trigger cells themselves 
and their values can be located. This is all that is needed to define die ancestor predicate (see 
Table 3-7). One cell is an ancestor of another if they have the same repository, or if the second is 
bound and the first is an ancestor of one of die triggers for die rule used to compute the second. 
(Another way to compute this would be: the first is an ancestor of the second if they have the same 
repository, or if any pin for which the first had been a trigger is an ancestor of the second. This 
searches from die top down rather dian the bottom up. However, a value may be a trigger for 
arbitrarily many other values, but any given value is computed from only as many trigger values 
as are required by the rule needing the greatest number of triggers (among all rules in the system). 
Intuitively, then, the fanout of the search procedure in fable 3-7 is guaranteed to be bounded, wile 
diat of the other is not. On the other hand, perhaps in typical use the typical value is a trigger for 
only one or two other values. I have not yet made measurements to determine which procedure is 
better in practice.) 

No change is necessary for handling the contradiction construct. On the other hand, 
setc and process-setc must be changed to install supplier and rule information (see Table 
3-8). With diis requirement, it is just as easy not to make up a fresh cell and equate it to the pin; 
instead, one might as well just do the relevant tests and install the new value (if indeed it is new) 
in die existing repository along with the supplier and rule information. If the pin to be set does 
not have a value, then the value and dependency information is installed and all interested parties 
awakened. If it docs have a value, then it had better be the same as the one we wish to install. 
Technically merge-values should be used here, but for now we omit this for the sake of giving 
a more precise error message. Similarly, a side benefit of having setc do some case analysis is that 
less ctrace output is generated; this version of setc only calls ctrace when a new value has 
been computed. 
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(defmacro setc (cellname value) 

j ‘(process-setc *me* cellname ,(symbolconc cellname "-CELL") ,value *rule*)) 

j(defun process-setc (*me* name cell value rule) 

(require-constraint *me*) 

(require-cell cell) 

(let {(sources (get rule 'trigger-names))) 

(cond ((not (node-boundp cell)) 

(ctrace "~S computed ~S for its part ~S~:[~2*~; from pin~P 
*me* value name sources (length sources) sources) 

(setf (node-contents cell) value) 

(setf (node-boundp cell) t) 

(setf (node-supplier cell) cell) 

(setf (node-rule cell) rule) 

(awakon-all (node-cells cell))) 

((not (equal (node-contents cell) value)) 

(lose "Contradictory values at ~S: ~S says ~S, but ~S says ~S." 
(cell-id cell) 

(node-supp1ier cell) 

(node-contents cell) 

*me* 

value))))) 

Compare this with Table 2-11 (page 57). 

Tahu-3-8. Definition of setc for Handling Dependencies. 


3.3. Producing Explanations 

All the machinery for maintaining dependency information in the constraint network is now 
in place. The remaining new code uses this information to generate explanations. 

The code for why appears in Table 3-9. it is complicated only because there are several cases, 
and because each case tries to format the output neatly. If the cell has no value, then this fact is 
stated; then all the possible ways of computing it in one step arc found and printed, or if none arc 
found this is stated. If the cell has a value, then the value is printed, and if the given cell is not the 
supplier the connection to the supplier is mentioned; then the supplier may be a constant or may 
be a pin of a constraint, and in the latter case the relevant rule and its triggers are printed. (The 
function cel 1 -goodname constructs a “good” name for the cell, one the user is most likely to 
find useful.) 

The information printed by why-ultimately includes the premises of the value asked 
about. These are all the values used to compute the given value which do not have any ancestors; 
that is, the premises arc the ultimate ancestor values of the given value. 

1 able 3-10 gives a straightforward but potentially inefficient algorithm for computing the set 
of premises, given a cell. If the cell has no value, it has no premises. If it is a constant, then it is its 
own premise. Otherwise the set of premises is the union of the sets of premises for die triggers of 
die rule used to compute the value in the cell. This algorithm is recursive, and performs a tree walk 
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(defun why (cel 1) 

(require-cell cell) 

(cond ((not (node-boundp cell)) 

(format t ;~S has no value." (cell-id cell)) 

(let ((flag ())) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(dolist (rule (ctype-rules (con-ctype (cell-owner c)))) 

(let ((trigger-names (get rule 'trigger-names)) 

(output-names (get rule 'output-names))) 

(cond ((memq (cell-name c) output-names) 

(format t I could compute it~;~ 

; o r~ ]" 

flag) 

(setq flag t) 

(format t from ~: [~2*~ ;pin~P of ~] 

~S by rule ~S" 


trigger-names 

(length trigger-names) 

trigger-names 

(con-name (cell-owner c)) 

rule))))))) 

(format t I don't have any way to compute it.~;.~]" flag))) 

(t (format t "~7,;The value ~S is in ~S because " 

(node-contents cell) (cell-id cell)) 

(let ((s (node-supplier cell))) 

(or (eq s cell) 

(format t "that is connected to and " (cel 1-goodname s))) 

(if (null (cell-owner s)) 

(format t "that is a constant.") 

(format t ~]~S computed it using rule ~S~ 

~0[~7o; from: ~:{~S (~S)~:[~*~; = 

(eq s cell) 

(cell-owner s) 

(node-rule s) 

(foriist (trigger-name (get (node-rule s) 'trigger-names)) 
(let ((cell (*the trigger-name (cell-owner s)))) 

(list (cell-id cell) 
trigger-name 
(node-boundp cel 1) 

(node-contents cell))))))))) 

'q.e.d.) 


(defun cel 1-goodname (cell) 

(require-cell cell) 

(cond ((globalp cell) (cell-name cell)) 

((constantp cell) (cell-id cell)) 

(t (list 'the (cell-name cell) (con-name (cell-owner cell)))))) 
TABLii 3-9. Code for why: Generating a One-Step Explanation. 


on the dependency structure. Inefficiency arises when the dependency graph is not strictly a tree, 
but contains many shared subtrees; in the worst case it may take exponential time in the si/.e of the 
network to compute that set, for example on the network of Figure 3-2. 
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(defun premises (cell) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) '()) 

(t (let ((s (node-supplier cell))) 

(if (null (cell-owner s)) 

(list s) 

(do ((tns (get (node-rule s) 'trigger-names) (cdr tns)) 

(p '() (unionq (premises (*the (car tns) (cell-owner s))) p))) 
((null tns) p))))))) 

Tabi.h 3-10. Calculation of the Premises Supporiing a Value. 



Table 3-11 gives an algorithm that avoids such exponential behavior by marking nodes as they 
are visited. The macros mark-node, unmark-node, and markp arc used to set, clear, and test 
a (normally clear) mark bit associated with each node. The structure of the algorithm is much 
the same, except that every node visited is marked, and when a marked node is encountered that 
branch of the search is cut off. Moreover, since every premise will be counted exactly once, the 
set-union operation un ionq (which eliminates duplicate entries) can be replaced by the faster list- 
concatenation operation nconc. After the set of premises has been collected, however, another 
pass is needed to clear all the marks again (because it is assumed that all marks are initially clear). 
Thus for dependency structures with no sharing of sub-trees this algorithm may be slower by a 
constant factor due to overhead (but remember that the first algorithm may be exponentially slower 
than the fast one in other cases!). 

Digression .Another possible approach depends heavily on an underlying garbage collector (which in fact 
exists in this usp-based implementation). Rather than using a mark bit, a mark object is used which 
is uniquely generated for each application of fast-premises. When fast-premises is called, it 
generates a new storage object, stores this object in the mark component of every visited node. Thus 
markp merely tests whether the mark component is this object. The generated object cannot be contused 
with one generated for either an earlier or a later call to fast-premises. Confusion could only arise 
if such an object were re-used while a pointer to it resided in some node; but the garbage collector 
guarantees that this cannot occur. (This idea is due to Gerald Jay Sussman.) 

One can say that a global process is needed so as not to confuse one marking with another. The 
function f ast-premises-unmark constitutes one such process. The technique discussed here pushed 
that work onto the garbage collector, an already existing global process. 
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(defniacro mark-node (cell) ‘(setf (node-mark ,cell) t)) 

(defmacro unmark-node (cell) ‘(self (node-mark ,cell) ())) 

(defmacro markp (cell) ‘(node-mark ,cell)) 

(defun fast-premises (cell) 

(require-cel 1 cell) 

(progl (fast-premises-mark cell) ( fast-premises-unmark cell))) 

(defun fast-premises inark (cell) 

(require-cel 1 cell) 

(and (node-boundp cell) 

(let ((s (node-supplier cell))) 

(cond ((markp s) '()) 

(t (mark-node s) 

(if (null (cell-owner s)) 

(list s) 

(do ((tns (get (node-rule s) ' trigger-names) (cdr tns)) 

(p '() (nconc (fast-premises-mark 

(*the (car tns) (cell-owner s))) 

P))) 

((null tns) p)))))))) 

(defun fast-premises-unmark (cell) 

(require-cel 1 cell) 

(let ((s (node-supplier cell))) 

(cond ((markp s) 

(unmark-node s) 

(or (null (cell-owner s)) 

(dolist (trigger-name (get (node-rule s) 'trigger-names)) 

(fast-premises-unmark (*the trigger-name (cell-owner s))))))))) 

Tabu: 3-11. Fast Calculation of Premises. 


Note that simply generating a number (the “bakery ticket” method) to use for a mark object doesn't 
quite work—if the si/e of a number is finite eventually some will be re-used. Only a global process 
keeping track of which numbers still reside in nodes can avoid confusion. 

The number of distinct mark objects simultaneously in existence need not exceed the number of 
nodes, plus one. 

{End of digression.) 

If a cell has no value, it is still possible to determine the set of potential premises of the cell: 
cells which, if they only had values, might eventually become premises because their values might 
contribute to a value for the cell of interest. The function desi red-premises in Table 3-12 
computes this set. It uses a graph-marking technique in the same manner as fast-premises. 
In this case cells which have no value arc of interest. The search is more complicated because at 
each step, if there arc several constraints attached to a node, no one of them is distinguished as 
the supplier, and no one rule distinguished as the generating rule; instead, all rules of all attached 
constraints which might possibly compute a value for that node must be considered and recursively 
searched. 
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(defun desired-premises (cell) 

(require-cell cell) 

(progl (desired-premises-mark cell) (desired-premises-unmark cell))) 

(defun desired-premises-mark (cell) 

(require-cell cell) 

(cond ((and (not (node-boundp cell)) 

(not (markp cell))) 

(mark-node cell) 

(do ((c (node-cells cell) (edr c)) 

(p '() (nconc (if (null (cell-owner (car c))) 

(and (globalp (car c)) (list (car 
(desired-premises-constraint (car 

P))) 

((null c) p))))) 

c))) 

c))) 

(defun desired-premises-constraint (cell) 

(requi re-cel 1 cel 1) 

(let ((p '())) 

(do1ist (rule (ctype-rules (con-ctype (cell-owner cell)))) 

(and (memq (cell-name cell) (get rule 'output-names)) 

(dolist (trigger (get rule 'trigger-names)) 

(setq p (nconc (desired-premises-mark 

(*the trigger (cell-owner cell))) 
P))))) 

P)) 


(defun desired-premises-unmark (cell) 

(require-cell cell) 

(cond ((and (not (node-boundp cell)) 

(markp cell)) 

(unmark-node cell) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(dolist (pin (con-values (cell-owner c))) 

(desired-premises-unmark pin))))))) 


(defun globalp (cel 1) 

(require-cell cell) 

(and (null (cell-owner cell)) (not (eq (cell-name cell) '?)))) 


Table 3-12. Determining Potential Premises for a Cell with No Value. 


(The function gl obal p is a predicate which is true of cells which arc neither pins nor con¬ 
stants.) 

The code for why-ul t imately ( fable 3-13), like that for why, divides into two cases. If 
the given cell is has no value, then that fact is staled, and if the set of desired premises is not empty 
its elements arc listed. If the cell has a value, then the possibilities that it is not the supplier and 
that the supplier is a constant arc considered, exactly as they arc for why. Then the set of premises 
is printed; all premises arc constants, of course, and so to help distinguish them any global names 
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(defun why-ultimately (cell) 

(require-cel1 cell) 

(cond ((not (node-boundp cell)) 

(format t "~%;~S has no value." (cell-id cell)) 

(format t "~@[ Perhaps knowing the value of 

~:15;~S ~>~tor ~}would help."]" 

(forlist (c (delq cell (desired-premises cell))) (cell-name c)))) 
(t (format t "~7, ;The value ~S is in ~S because " 

(node-contents cell) (cell-id cell)) 

(let ((s (node-supplier cell))) 

(or (eq s cell) 

(format t "that is connected to and " (cel 1-goodname s))) 

(if (null (cell-owner s)) 

(format t "that is a constant.") 

(format t "it was ultimately derived" 

~S[ from:~:{~%; ~S~@{ == ~S~}~:t." 

(forlist (p (premises s)) 

(cons p (mapcan #'(lambda (c) 

(and (globalp c) 

(list (cell-name c)))) 
(node-cells p))))))))) 

' q . e . d.) 

Tabit, 3-13. Implementation of why-ultimately. 


attached to a premise arc also printed, preceded by = = . 4 

That’s all there is to why and why-ul timately. Simple, is it not? 

The only difficulty with these explanation mechanisms is that one provides very local informa¬ 
tion, and the other the most global possible information; neither provides any sense of how the 
local situation is related to its surroundings. Of course, the user can use why to chase down the 
computation step-by-step, but that can produce a very long explanation full of trivial details. A long 
linear explanation at the lowest level is much less useful than a short one mentioning high-level 
goals. 


4. If the set of premises is empty, then the output will say “The value 43 is in ClT. 1-27 because it was ultimately 
derived.” which is admittedly cryptic. This shouldn't happen with the particular primitive constraints shown so far, 
but could with more bizarre constraint-types. Part of the art of designing format messages is arranging for the 
boundary cases and conditional cases always to be grammatical! 
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Consider die following subtraction problem ... 

342 — 173 

Now. remember how we used to do that: three from two is nine, carry the one: and if 
you're under 35 or went to a private school you say seven from three is six. but if you're 
over 35 and went to a public school you say eight from four is six: and carry the one, 
so you have 169. 

But in the new approach, as you know, the important thing is to understand 
what you're doing rather than to gel the right answer. Here's how they do it 
now: 


Now instead of four in (he tens place. 
You've got three. 

'Cause you added one — 

That is to say. ten — 

To the two. but you can't 

Take seven from three 

So you look in the hundreds place. 

From the three 

You then use one 

To make ten ones 

And you know why four 

Phis minus-one plus ten 

Is fourteen minus one: 

'Cause addition is commutative! Right! 
And so you have thirteen tens 
And you take away seven 
and that leaves five! 

(Well ... six, actually, ... 
but the idea is the important thing.) 


You can't take three from two. 

Two is less than three. 

So you look at the four 
In the tens place. 

Now. that's really four tens. 

So you make it three tens. 

Regroup, 

And you change a ten to ten ones. 

Then you add to the two and get twelve 
And you lake away three — that's nine. 

(Is that clear?) 


Now you go back 
To the hundreds place. 

You're left with two 
And you Jake away one 
From two, and that leaves ... 

(Everybody get one? Not bad for the first day.) 

Hooray for New Math, 

New-ew-ew Math, 

It won 7 do you a bit of good to review math: 
It's so simple. 

So very simple. 

That only a child can do it! 

—Tom I .ehrer (1965) 

“New Math” 

That Was The Year That Was 
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3.4. Representing Symbolic Results in the Network 

Wc return now to the problem encountered at the end of §3.1: what explanation can be given 
when the computation fails to make progress? More generally, what explanation can be given 
that is less local than the onc-stcp explanation of why but less distant than the leaves of the tree 
searched by why-ul t imately? The ultimate explanation of whatever computation did or did 
not occur certainly lies in the network itself, but it is not necessarily helpful simply to print the 
entire network, partly because the network may be huge, and partly because it may be that most 
of the network is irrelevant to the needed explanation. (By way of comparison, it is not of direct 
help to answer a question like, “What are the colors of the rainbow?” by handing the inquirer an 
encyclopedia—particularly if the encyclopedia is not alphabetized!—expecting him to read it all to 
get an answer to his question.) 


3.4.1. Subgraphs of the Network May Be Printed as Algebraic Expressions 

Here we present a new function what which produces an explanation for a cell by copying 
a carefully chosen part of the network structure, with directions assigned to edges such that the 
chosen part is an acyclic directed graph and the cell of interest is at the root, and printing that 
part as nested algebraic expressions. Suppose once again that wc have created a fresh temperature 
conversion network. 

(what fahrenheit) 

;CELL-99 has no value. I can express it in this way: 

; FAHRENHEIT = (+ (// (* 9 CENTIGRADE) 5) 32) 

OKAY? 

(what centigrade) 

;CELL-100 has no value. I can express it in this way: 

; CENTIGRADE = (// (* (- FAHRENHEIT 32) 5) 9) 

OKAY? 

The function what is not performing transformations on algebraic expressions in the usual general 
sense. Each the algebraic expressions above is merely a way of printing (a part of—in this case the 
whole of) the network. 

(what (the c mult)) 

;CELL-94 has no value. I can express it in this way: 

; (THE C MULT) = (* (- FAHRENHEIT 32) 5) 

OKAY? 

(what (the c othermult)) 
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;CELL-98 has no value. I can express it in this way: 

; (THE C OTHERMULT) = (* 3 CENTIGRADE) 

OKAY? 

The c pins of the two multipliers arc connected together. However, what prints two different 
expressions for them because it avoids (as a heuristic) using a constraint as part of the explanation 
for a valueless pin of that constraint. 

(variable foo) 

<CELL-104 (FOO): no value> 

(== (the c mult) foo) 

DONE 

(what fahrenheit) 

;CELL-99 has no value. I can express it in this way: 

; FAHRENHEIT = ( + (// FOO 5) 32) 

OKAY? 

(what centigrade) 

;C.ELL-100 has no value. I can express it in this way: 

CENTIGRADE = (// FOO 9) 

OKAY? 

Another heuristic is that nodes with explicit global names arc a good stopping place. It is not neces¬ 
sary to print the entire network—-just to indicate relationships to the “nearest neighbors” which 
have “meaning” to the user. If the meaning of f oo is not clear, one can ask what that is. 

(what foo) 

;CELL-104 has no value. I can express it in this way: 

; FOO = (* (- FAHRENHEIT 32) 5) 

OKAY? 

Now foo could be expressed in terms of either fahrenheit or centigrade; what hap¬ 
pened to choose tine former. There may be many equivalent expressions to use; it is not desirable to 
print them all, and not easy to choose the best. [McAllcstcr 1980] The version of what presented 
here has only a few heuristics, and to simplify the presentation, no way has been provided to 
change them. It will serve as a modest example of what can be done, however. 

Let cent igrade be given the value—40. 

(== centigrade (constant -40)) 

;|Awakening <MUL.T :MULTIPLIER-91> because its B got the value -40. 

; |<MULT:MULTIPLIER-91> computed -360 for its part C from pins A, B. 
;|Awakening COTHERMULT:MULTIPLIER-95> because its C got the value -360. 

;|<OTHERMULT:MULTIPLIER-95> computed -72 for its part A from pins B, C. 
;|Awakening <ADD:ADDER-87> because its A got the value -72. 

;|<ADD:ADDER-87> computed -40 for its part C from pins A, B. 

;|Awakening <ADD:ADDER-87> because its C got the value -40. 

;|Awakening <OTHERMULT:MULTIPLIER-95> because its A got the value -72. 
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;|Awakening <MULT:MULTIPLIER-91> because its C got the value -360. 
DONE 


Note that much less ct race output is generated this time (thanks to the changes to process-setc 
in Table 3-8). 

(what fahrenheit) 

;The value -40 in CELL-99 was computed in this way: 

; FAHRENHEIT «- (+ (// (* 9 CENTIGRADE) 5) 32) 

; CENTIGRADE <- -40 
OKAY? 


In this case the heuristic is to explain the value completely. The entire computation is printed. In 
order to take advantage of nested expression notation, what avoids using intermediate names like 
Too. However, it docs use the name cent i grade to identify the constant — 40 to distinguish it 
from the other constants. The variable name foo still exists, of course; what has merely chosen 
not to use it. 


(what foo) 

;The value -360 in CELL-104 was computed in this way: 
; FOO <- (* 9 CENTIGRADE) 

; CENTIGRADE <- -40 

OKAY? 

(what centigrade) 

;The value -40 in CELL-100 was computed in this way: 

; CENTIGRADE «- -40 
OKAY? 


I Explanations of intermediate stages are also easily generated. This time foo is explained in terms 
of centigrade rather than f ah renhe i t, since the value was derived from centigrade. 

Now suppose that instead of —40, the value 37 is given to cent igrade (in a fresh tempera¬ 
ture conversion network). Recall that this computation will “fail” because of inexact division. 

(== centigrade (constant 37)) 

;|Awakening <MULT:MULTIPLIER-110> because its B got the value 37. 

;|<MULT:MULTIPLIER-110> computed 333 for its part C from pins A, B. 
;|Awakening <OTHERMULT:MULTIPLIER-114> because its C got the value 333. 
;|Awakening <MULT:MULTIPLIER-110> because its C got the value 333. 

DONE 

(what fahrenheit) 

;CELL-118 has no value. I can express it in this way: 

; FAHRENHEIT = (+ (// 333 5) 32) 

OKAY? 
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PI P2 P3 P4 



Here what claims that fahrenheit “has no value”. However, it is able to print out an expres¬ 
sion for it entirely in terms of constants. Rxcept that it is not in reduced form, this is the form of 
answer we might expect anyway: a mixed number. 5 

The ability of what to deal reasonably with networks containing cycles has not been 
demonstrated, as the temperature conversion network has no cycles. For another example let us use 
an extension of the network of Figure 2-10 (page 64) for spacing four points equally (see Figure 3- 

3). 


(defun test () 

(variable pi) 
(variable p2) 
(variable p3) 

(variable p4) 
(create al2 adder) 
(create a23 adder) 
(create a34 adder) 


(== 

(the 

a 

al2) 

Pi) 


(== 

(the 

c 

al2) 

p2) 


(== 

(the 

b 

al2) 

(the b 

a23)) 

(== 

(the 

a 

a23) 

P2) 


(== 

(the 

c 

a23) 

p3) 


(== 

(the 

b 

a23) 

(the b 

834)) 

(== 

(the 

a 

a34) 

P3) 


(== 

(the 

c 

a34) 

p4)) 



TEST 


5. Production of a reduced form cannot be done purely by local propagation anyway: it requires algebra. The steps are: 
32 + 333/5 -> 32 + (330 + 3)/5 -+ 32+ (330/5+3/5) -> 32+ (06 + 3/5) -+ (32+00)+ 3/5 -+ 98 + 3/5, 
which requires (among other things) distribution of division over addition and associativity of addition, as well as 
two simple local arithmetic operations and one “non-dctcrministic” (actually guided by the requirements of “reduced 
form”) reverse-addition splitting of 333 into 330 + 3. 
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FiGliRH 3-4. Computing F.qual Spacing for Four Points. 


These arc all the statements For constructing the Four-point equal-spacing network, packaged up as 
a LISP function called test. Bxccuting this function will thus construct an instance of the equal¬ 
spacing network. 6 


(TEST) 

DONE 


(what pi) 

;CELL-151 lias no value. I can express it in this way: 
; PI = (- P2 (- P3 P2)) 

OKAY? 

(what p2) 

;CELL-152 has no value. I can express it in this way: 
; P2 = (- P3 (- P2 PI)) 

OKAY? 


(what p3) 

;CELL-153 has no value. I can express it in this way: 
; P3 = (- P4 (- P2 PI)) 

OKAY? 

(what p4) 

;CE LL-154 has no value. I can express it in this way: 
; P4 = (+ P3 (- P2 PI)) 

OKAY? 


In each case, what doesn’t run off and print the entire network, but just enough to give a feel For 
the local connections. Note that three of the equations arc not circular; this is somewhat acciden¬ 
tal. However, in describing pi the expression (- p3 p2) was used rather than (- p2 pi) 
because the adder needed for the latter had already been used For the outer subtraction. In this 
limited (and locally defined!) sense, circularity is avoided in the explanations. 

6. Use of a LISP function definition in this way is of course also outside the defined constraint language. Tliis is yet 
another example of how the facilities of the meta-languagc can be used to augment the usability of a toy language 
until the latter grows to the point of providing such facillies itself. Defining and using a function like test is much 
easier than typing a dozen or two statements each time the network is needed. F.venlually an equivalent facility will 
be provided in the constraint language itself. 
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(== pi (constant 3)) 

;|Awakening <A12:ADDER-155> because its A 
DONE 

(== p2 (constant 5)) 

;|Awakening <A23:ADDER-159> because its A 
;|Awakening <A12:ADDER-155> because its C 
;|<A12:ADDER-155> computed 2 for its part 
;|Awakening <A12:ADDER-155> because its B 
;|Awakening <A23:ADDER-159> because its B 
; | <A23:ADDER-159> computed 7 for its part 
;|Awakening <A34:ADDER-163> because its A 
; |<A34:ADDER-163> computed 9 for its part 
;|Awakening <A34:ADDER-163> because its C 
;|Awakening <A23:ADDER-159> because its C 
;|Awakening <A34:ADDER-163> because its B 
DONE 

Presumably now p3 — 7 and p4 = 9. (See Figure 3-4.) 
(what p3) 

;The value 7 in CELL-153 was computed in 
; P3 «- (+ P2 (- P2 PI)) 

; P2 <- 5 

; PI 3 

OKAY? 


got the value 3. 


got the value 5. 
got the value 5. 

B from pins A, C. 
got the value 2. 
got the value 2. 

C f rom pins A, B. 
got the value 7. 

C from pins A, B. 
got the value 9. 
got the value 7. 
got the value 2. 


this way: 


Okay! This is a reasonable explanation. Again, note that if a constant has a global name associated 
with it, that name is used. 

(what p4) 

;The value 9 in CELL-154 was computed in this way: 

; P4 <- (+ (+ P2 (THE B A12)) (THE B A12)) 

; (THE B A12) <- (- P2 PI) 

; P2 <- 5 

; PI <- 3 

OKAY? 


Here the result of the computation (- p2 pi) must be used twice in the expression describing 
p4 because in fact the value was used in two different ways during the course of the computation. 
However, what avoids giving the impression that parts of the network arc duplicated. Since there 
is no global name for the intermediate quantity, the name (the b a 12) of the supplying pin is 
used to name the quantity. 

(variable spacing) 

<CELL-169 (SPACING): no value> 

(== spacing (the b al2)) 

DONE 
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(defun what (cell) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) 

(format t has no value. I can express it in this way:~ 

~: {~°/o; ~S = ~S~}" 

(cell-id cell) (tree-form cell t))) 

(t (format t The value ~S in ~S was computed in this way:~ 

~ : {; ~S «- ~S~}" 

(node-contents cell) (cell-id cell) (tree-form cell)))) 

'okay?) 

TAHLE3-14. Ocfinition of the what Explanation Function. 


(what p4) 

;The value 9 in CELL-154 was computed in this way: 
; P4 <- (+ ( + P2 SPACING) SPACING) 

; SPACING «- (- P2 PI) 

; P2 *- 5 
; PI «- 3 
OKAY? 


Once a global name has been supplied, however, what is happy to use it instead. 


(what p3) 

;The value 7 in CELL-153 was computed in this way: 

; P3 «- (+ P2 (“ P2 P1 )) 

; P2 «- 5 

; PI «- 3 

OKAY? 


On the other hand, the extra name is not used if it is not necessary to avoid duplicating expressions. 

The general aim of the what function is to print a relevant portion of the network. If die 
portion contains no values, as little as possible is printed to relate the cell of interest to globally 
named cells and constants. If die cell of interest contains a value, then the entire computation 
of that value is displayed (which for a large network might still be too much, actually); nested al¬ 
gebraic expressions are used as much as possible, but intermediate names are introduced to denote 
constants and quantities which must be mentioned more than once. Whenever an intermediate 
quantity must be named an attempt is made to locally determine the “best” name for it; but no 
more global criterion is used to choose one expression over another. [McAllcstcr 1980] 
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(defmacro nummark (cell) 

‘(setf (node-mark ,ce!1) 

(if (numberp (node-mark ,cel1)) (+ (node-mark ,cell) 1) 1))) 
(defmacro unnummark (cell) ‘(setf (node-mark ,cell) ())) 

(defmacro nummarkp (cell) ‘(numberp (node-mark ,cell))) 

(defmacro singlenummarkp (cell) ‘(equal (node-mark ,cell) 1)) 

(defprop adder ((c (+ a b)) (b (- c a)) (a (- c b))) treeforms) 

(defprop multiplier ((c (* a b)) (b (// c a)) (a (// c b))) treeforms) 
(defprop maxer ((c (max a b)) (b (arcmax c a)) (a (arcmax c b))) treeforms) 
(defprop minner ((c (min a b)) (b (arcmin c a)) (a (arcmin c b))) treeforms) 
(defprop equality ((p (= a b)) (b (arc= p a)) (a (arc= p b))) treeforms) 
(defprop gate ((p (0-if-unequal a b)) (b (-> p a)) (a (-> p b))) treeforms) 

(defun tree-form (cell &optional (shallow ())) 

(requ i re-cel 1 cel 1 ) 

(nummark cell) 

(prog2 (tree-form-trace cell shallow) 

(tree-form-gather cell shallow) 

(tree-form-unmark cell))) 

Tabu- 3-15. The tree-form Function and Macros for Numerical Marks. 


3.4.2. Choosing a Subgraph is Guided by Dependencies and Better-Name Heuristics 

The code for what itself is fairly simple (Table 3-14), but it uses a rather complicated mark¬ 
ing routine tree-form. T his routine traces out an appropriate subgraph of the network graph, 
marking it out as it goes, then copies the subgraph in the form of a USE s-exp cession (actually a list 
of equations), and finally cleans up by resetting all mark bits. 

The tree-form function, like fast-premises and des i red-premises, uses graph¬ 
marking techniques. In this case, however, a three-state mark bit is required, because it is of interest 
to know whether a node has been visited not at all, once, or more than once. T hus the mark may be 
thought of as a reference count, possibly with a ceiling at 2. The macros nummark, unnummark, 
and nummarkp ('fable 3-15) implement such a reference count (with no ceiling) using the mark 
component of the node’s repository. T he normal value of such a counter should be zero, but for 
compatibility with the other graph-tracing routines these macros arrange to treat false as zero. 

Also in Table 3-15 is a little data base of algebraic forms to use when copying portions of 
the network. Associated with each constraint-type is a table which, for each pin of a constraint, 
illustrates how to represent that pin in terms of other pins (not necessarily all the others, though 
that is so for our example constraint-types) in USE prefix form. Thus for an adder the c pin can be 
represented as the sum of a and b, the b pin as the difference of c and a, and so on. 7 

7. Actually, these formats might more usefully be associated with individual rules to handle special cases—for example, 
in the case of multiplication by zero, the value of the other input need not enter into the expression. However, it 
was done this way (the “kludge it in quickly by hanging it from a properly list” technique) so as not to have to 
again revise the format of defrule; after all, this data base is a specialized one purely for the benefit of what.) 





§ 3.4.2 


Representing Symbolic Results in the Network 


97 


The function tree-form first marks the given node by using nummark; then it calls 
tree-form-trace to trace out a subgraph of interest; next it uses tree-form-gather to 
copy the traccd-out subgraph as a 1.ISP list of equations; and finally it asks tree-form-unmark 
to clean up the marker counts. 

The function tree-form-trace ( lable 3-16) recursively marks out a subgraph explaining 
the value or non-value of the given node, the general idea is that if the node has a value, then we 
are tracing out, by following the supplier chain, the computation which produced the value; but if 
the node has no value, then we trace out any single potential computation. 

The node given to tree-form-trace must already have been marked by the caller, and 
determined by the caller to have been the first time that node was marked. ( This is trivially die 
case for the top-level invocation of tree-form-trace within tree-form.) The shallow 
flag indicates whether or not a full tracing out is desired: if it is set, the tracing may stop when a 
node with a value or a global name is encountered; but if not, then it must proceed until it can go 
no farther. If the node has a value, then the supplier is examined. If it has an owner, then it is a pin 
of that owner, and the computations for the sources (the input pins for the rule that computed the 
value for the supplier) arc recursively traced, unless the shallow flag is true. If the supplier has 
no owner, it is a constant, and as a special kludge it is marked again; the effect of this is to make it 
appear to be visited more than once, which will cause t ree-form-gathe r to try to find a name 
for it (see below). If the node has no value, then a supplier is artificially and arbitrarily chosen for 
the cell. If the shallow flag is set, then the artificial supplier will preferably be a global cell; if not, 
then preferably a pin of a constraint. If no other cell of the node will do, then as a last resort the 
given cell is deemed to be its own supplier; if it is a pin, then tree-form-deep-trace is called 
to trace its sources. 

The function tree -f orm-trace-set takes a constraint and a list of pin names and traces 
from all the pins named. It first marks each of the pins, and adds those visited for the first time to 
a queue; then all the nodes on the queue arc traced. It is very important that all pins be marked 
before any are traced—otherwise circular explanations can arise. The function tree-f orm-tag 
marks a node, then returns a list of the node (i.c., of its representative cell) if the node had 
previously been unmarked, and otherwise returns an empty list. 

Digression .Looking back on it, tree-form-tag might have been written more simply as: 

(defun tree-form-tag (cell) 

(nummark cel 1) 

(and (singlenummarkp cell) (list cell))) 

1 wonder why I did it the more complicated way? Probably because I was thinking of the cell as being 
unmarked before the visit, rather than as begin singly marked after the visit. I have decided to show 
both versions here to indicate how one's point of view can affect the way a program is written. 

(End of digression.) 
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(defun tree-form-trace (cell shallow) 

(require-cel 1 cell) 

(cond ((node-boundp cell) 

(let ((s (node-supplier cell))) 

(cond ((cell-owner s) 

(or shallow 

(tree-form-trace-set (cell-owner s) 

(get (node-rule s) 'trigger-names) 
shallow))) 

(t (nummark cell))))) ;crock 

(t (let ((cells (node-cells cell))) 

(setf (node-supplier cell) 

(or (if shallow 

(or (tree-form-shallow cell cells) 

(tree-form-deep cell cells shallow)) 

(or (tree-form-deep cell cells shallow) 
(tree-form-shallow cell cells))) 

(if (cell-owner cell) 

(tree-form-deep-trace cell shallow) 
cell))))))) 

(defun tree-form-trace-set (owner names shallow) 

(do ((n names (cdr n)) 

(queue '() (nconc (tree-form-tag (*the (car n) owner)) queue))) 

((null n) (dolist (c queue) (tree-form-trace c shallow))))) 

(defun tree-form-tag (cell) 

(and (not (progl (nummarkp cell) (nummark cell))) 

(list cell))) 

(defun tree-form-shallow (cell cells) 

(do ((c cel Is (cdr c))) 

((null c) ()) 

(and (not (eq (car c) cell)) 

(globalp (car c)) 

(return (car c))))) 

(defun tree-form-deep (cell cells shallow) 

(do ((z cells (cdr i ))) 

((null z) ()) 

(and (not (eq (car z) cell)) 

(cell-owner (car z)) 

(return (tree-form-deep-trace (car z) shallow))))) 

(defun tree-form-deep-trace (cell shallow) 

(let ((treeform 

(cadr (assq (cell-name cell) 

(get (ctype-nanie (con-ctype (cell-owner cell))) 

' treeforms))))) 

(tree-form-trace-set (cell-owner cell) (cdr treeform) shallow) 
cell)) 

Table 3-16. Tracing Out a Subgraph of Interest for what. 


'The function tree-form-shal 1 ow tries to find a global cell in the current node which is 
not the given cell. Similarly, tree-form-deep tries to find a pin in the current node other than 
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the given cell (and if it finds one, it recursively traces die sources, using tree-form-deep-trace, 
which determines the sources by looking at the tree forms data base.) Bach of these functions 
returns the desirable pseudo-supplier cell, or false if no desirable cell is found. In tliis way they 
signal success or failure, and die LISP or construct can be used to try one method and then another 
in tree-form-trace. 

The function tree-form-gather (Table 3-17) retraces the subgraph, starting from die 
same cell that tree-form-trace did, and copies the traced subgraph. It returns a list of equa¬ 
tions. Bach equation is represented as a list of the left-hand side and the right-hand side. The left- 
hand side is always the name of a cell; die right-hand side is a formula. Hence, taken in the correct 
order (roughly last to first, though this property is not guaranteed), these equations represent a set 
of I ORTRAN-stylc assignment statements for die computation. 

The general idea is that the tree traced is copied as an algebraic expression. Whenever a node 
is encountered which has been marked more than once, then the computation for that node must 
be expressed as a separate equation defining a name for that node; then the name for that node 
can be used in other equations to represent that node. This is necessary to avoid duplication of 
shared sub-computations. Nodes which have been marked more dian once arc called cuts, because 
they divide the traced subgraph into portions which are trees in the strict sense. Bach of these strict 
trees can be represented by a nested algebraic expression, but each cut requires a new equation. 
(The kludge in tree-form-trace mentioned above, where a constant is purposely marked an 
extra time, is to delude tree-form-gather (actually tree-form-chase) into thinking that 
the constant is a cut; this will force it to try to create an extra equation in order to give a name to 
the constant.) 

A queuing mechanism is used within tree-form-gather. The variable *cuts* contains 
a queue of nodes which are cuts and which have yet to have equations computed for them. 
At each iteration one cut node is dequeued and the strict tree it heads is recursively copied by 
tree-form-chase, which when it reaches the leaves of the struct tree may enqueue other cut 
nodes. The variable *allcuts* contains the set of all nodes ever enqueued onto *cuts*; 
this is used to prevent die same cut node from being enqueued more than once. The list 
♦ extra-equations* is a list of equations added to by tree-form-chase when an equation 
to name a constant must be created. This is kept as a separate list rather than adding these extra 
equations directly to the list in equations purely so that all such named constants will appear at 
the end of the final list of equations. 

The first thing tree-form-chase does is check the supplier of the given node; this may be 
a true supplier (if the node has a value), or an artificial supplier (if it does not). If die node has a 
value and the shal low flag is set, then die value itself represents the node. Now top is a flag 
indicating whether or not this call to tree-form-chase is on the root of a strict tree (which may 
occur if the node is the node given to what, or if the node is a cut node). Only if this is not die top 
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(declare (special *cuts* *allcuts* *extra-equations*)) 

(defun tree-form-gather (cell shallow) 

(require-cel 1 cel 1) 

(do ((*cuts* (list cell)) 

(*al1 cuts* (list cell)) 

(equations ' ()) 

(♦extra-equations* '())) 

((null *cuts*) (nreverse (append *extra-equations* equations))) 

(let ((cut (pop *cuts*))) 

(push (list (cel 1-goodname cut) (tree-form-chase cut shallow t)) 
equat ions)))) 

(defun tree-form-chase (cell shallow top) 

(require-cel 1 cell) 

(let ((s (node-supplier cell))) 

(cond ((and shallow (node-boundp cell)) (node-contents cell)) 

((and (not top) (not ( s i ng 1 enuinmarkp s))) 

(cond ((constantp s) 

(do ((c (node-cells s) (cdr c))) 

((null c) (node-contents s)) 

(cond ((globalp (car c)) 

(cond ((not (meinq (car c) *allcuts*)) 

(push (car c) *allcuts*) 

(push (list (cell-name (car c)) (node-contents s)) 
♦extra-equations*))) 

(return (cell-name (car c))))))) 

(t (let ((best (do ((c (node-cells s) (cdr c))) 

((null c) s) 

(and (not (eq (car c) s)) 

(globalp (car c)) 

(return (car c)))))) 

(cond ((and (not (and (eq best s) (globalp s))) 

(not (memq best *allcuts*))) 

(push best *allcuts*) 

(push best *cuts*))) 

(cel 1-goodname best))))) 

((cell-owner s) 

(let ((treeform (cadr (assq (cell-name s) 

(get (ctype-name (con-ctype (cell-owner s))) 

'treeforms ))))) 

(cons (car treeform) 

(forlist (n (cdr treeform)) 

(cond ((and (node-boundp s) 

(not (memq n (get (node-rule s) 'trigger-names)))) 
'?) ' 

(t (tree-form-chase (*the n (cell-owner s)) 

shallow 

()))))))) 

((globalp s) (cell-name s)) 

(t (node-contents s))))) 

Table 3-17. Copying a Traced Subgraph as a Sel of Equations. 


node does tree-form-chase want to check for its being a cut node (visited more than once by 
tree-form-trace). If it is a cut node other than the top, then the supplier may be a constant or 
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something else. If a constant, then an attempt is made to find a global cell within the same node, to 
serve as a name for the constant. If one is found, that is returned, and an equation identifying the 
name with the constant is added to *extra-equat ions* (if it has not already been added); but 
if one is not found, the constant itself is returned. If the cut node’s supplier is not a constant, then 
a similar search for a global name is made; either such a name, or else the supplier’s name (which 
if the supplier is a pin looks like (the f oo bar)), is chosen to name the cut node. The node is 
queued as a cut node if it has not already ever been queued and if the supplier is not a global cell 
artificially chosen to be the supplier (in which case there is no way to express that name in terms of 
something else, so no equation is needed). 

If die node is not to be treated as a cut node, then there arc three cases: the supplier may be a 
constant, a global cell, or a pin. For a constant the value is returned; because tree-form-trace 
always marks nodes with constant suppliers as cut nodes, this case can only arise when the top 
flag is set. For a global cell, its name is returned; this can only occur when the global cell has 
been chosen as an artifical supplier. For a pin, the associated expression form is fetched from the 
treeforms data base; then each input pin named in the expression form is recursively chased 
and die resulting expression filled in as a sub-expression of the treefonn for this node. An excep¬ 
tion is that if this node has a value, then the rule used to compute it is examined, and if an input pin 

named in the expression form was not actually a trigger for the rule, then “?” is filled in for that pin 

in the form. This is a crude attempt to take into account things like the multiplication-by-zcro rule. 
For example: 

(create m multipiier) 

<M:MULTIPLIER-44> 

(what (the c m)) 

;CELL-47 has no value. I can express it in this way: 

; (THE C M) = (* (THE A M) (THE B M)) 

; (THE B M) = (// (THE C M) (THE A M)) 

; (THE A M) = (// (THE C M) (THE B M)) 

OKAY? 

(This is an example of a strange case that occurs when a node is a “dead end” (a leaf of the 
computation tree) for the tree-form-trace search, and the node’s sole cell is a pin. The pin 
must serve as its own supplier, and so tree-form-chase believes that dais supplier must be 
expressed as an expression. If global names were given to (the a m) and (the b m) then this 
anomaly would not occur. Alternatively, the tree-form code could be made more complex, but 
I didn’t feel like doing this.) 

(== (the a m) (constant 0)) 

;|Awakening <M:MULTIPLIER-44> because its A got the value 0. 

;|<M:MULTIPLIER-44> computed 0 for its part C from pin A. 

;|Awakening <M:MULTIPLIER-44> because its C got the value 0. 

DONE 
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(defun tree-form-unniark (cell) 

(require-cel 1 cell) 

(cond (( nmmnarkp cell) 

(unnummark cell) 

(let ((s (node-supplier cell))) 

(and (cell-owner s) 

(dolist (pin (con-values (cell-owner s))) 

(tree-fonn-unmark pin)))) 

(or (node-boundp cell) (setf (node-supplier cell) ()))))) 

Tabu:3-18. Resetting the Mark Components for tree-form. 


(what (the c m)) 

;The value 0 in CELL-47 was computed in this way: 

; (THE C M) «• (* 0 ?) 

OKAY? 

The explanation indicates that ( the c m) is the product of zero and something we don’t much 
care about (because the rule didn’t). 

(what (the b in)) 

;CELL-46 has no value. I can express it in this way: 

; (THE B M) = (// 0 0) 

OKAY? 

Certainly (the b m) = 0/0; of course, this defines no particular value, but then again, 
(the b m ) indeed has no particular value. 

The function tree-form-unniark (fable 3-18) is similar to fast-premises-unmark 
(fable 3-11) and desi red-premi ses-unmark (fable 3-12), with the additional feature that if 
a marked node is encountered which has no value, then that node’s supplier is reset to the null 
supplier; this removes the artificial suppliers introduced by tree-form-trace. 


3.5. Summary of Some Uses for Dependencies 

The facilities described in this chapter illustrate the recording and some the uses of depend¬ 
ency information. Recording dependencies amounts to remembering the history of the local 
propagation. All such histories must be embedded within the structure of the constraint network; 
the computation history can be represented as the directions of information flow within the net¬ 
work, plus the computational rules used to compute new values. 

Even if a computation has not been performed, or has propagated values to only as part of the 
network, the structure of the network can be used to advantage, because it describes all possible 
potential histories. These potential histories, if few in number or carefully chosen among, may be 
useful for analyzing the situation. 
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Three procedures for examining a constraint network have been exhibited. The function why 
traces a single actual computation step or all potential single computation steps. The function 
why-ul timately traces through an entire actual computation tree (actually a dag—a tree, pos¬ 
sibly with shared subtrees) or through all possible potential trees, in effect, and exhibits the leaves 
of the trees. The function what traces through an entire actual computation tree or a single, 
carefully chosen potential tree, and exhibits that tree as an algebraic expression, indicating shared 
subtrees by naming them and then defining the name once to be the shared sub-expression. 

There are other ways of using the dependency information. For example, the notion dual 
to that of the set of premises is known as the set of repercussions '—it is the set of nodes which 
have a given node as an ancestor and which are not ancestors of any other nodes. In other 
words, the repercussions arc the ultimate consequences of a node. Functions for tracing through 
the network and locating the repercussions and then printing the findings in a manner similar to 
why-ul t imatel y or wha t would be useful. 



Little fishies in the brook. 

All they do is look and look. 

Christmas comes but once a year. 
My dad drives a peanut wagon! 

—Cordon Ruthvcn Kerns 
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gj N 'l lII*: CONSTRAINT SYSTI-M developed in Chapters Two and Three, if a constant is mistakenly 
JL connected to the wrong node, that’s too bad; the user must start over from scratch. If the user 
wants to use a single network to explore several cases, to tinker with parameters to see the resulting 
effects, that also is too bad. Once a value has been computed for a node, it is fixed for all time, 
'frying to change it will only produce a contradiction, causing the signalling of an irrecoverable 
error. 

Mechanisms for retracting values will be developed in this chapter. This is not simply a matter 
of throwing away old values and installing new ones. Values associated with other nodes may 
have been computed from the retracted one, and these must also be retracted. Moreover, when a 
contradiction occurs, it may be “far from the scene of the crime”; the contradiction may involve 
not premises but derived values. Retracting a derived value docs no good—the same value will 
be recomputed from the premises. Instead, one of the premises of one of the contradictory values 
must be retracted. Of course, the premise-tracing machinery developed in Chapter Three will be of 
use for this. 


4.1. Forgiving Systems 

Many computer systems require a great deal of forgiving (though few deserve it), but here l 
mean that the system is forgiving—of mistakes, changes of mind, and so on. Ideally one would like 
to be able to invert any action with an appropriate counter-action, and have the state of the system 
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be as if the action had never taken place. Here follow examples of the system allowing the user to 
change his mind when some action causes a contradiction. 


4.1.1. Connecting Conflicting Cells Can Cause Contradictions 

Let us re-enact the example of §2.3, where we constructed a temperature conversion network, 
equated centigrade to —40 (which of course computed —40 for fahrenheit), and then 
equated fahrenheit to 32. 

(defun temp-converter () 

(create add adder) 

(create mult multiplier) 

(create othermult multiplier) 

(variable fahrenheit) 

(variable centigrade) 

(== fahrenheit (the c add)) 

(== (the b add) (constant 32)) 

(== (the a add) (the a othermult)) 

(== (the c othermult) (the c mult)) 

(== (the b othermult) (constant 5)) 

(== centigrade (the b mult)) 

(== (the a mult) (constant 9))) 

TEMP-CONVERTER 

This is die same definition for a temperature converter we used in Chapters Two and Three, 
packaged up as a single USP function. 

(temp-converter) 

;|Awakening <ADD:ADDER-23> because its B got the value 32. 

; (Awakening <0THERMIJLT: MULTIPLIER-31> because its B got the value 5. 

;|Awakening <MULT:MULTIPLIER-27> because its A got the value 9. 

DONE 

Now diat the network has been instantiated, we equate centigrade to —40. Rather than using 
the constant construct, however, we shall use default instead. This has roughly the same 
effect; the only difference is that a default is tentative, while a constant is relatively fixed (but only 
relatively). 

(== centigrade (default -40)) 

;|Awakening <MULT:MULTIPLIER-27> because its B got the value -40. 

; |<MULT:MULTIPLIER-27> computed -360 for its part C from pins A, B. 

;|Awakening <OTHERMULT:MULTIPLIER-31> because its C got the value -360. 

;|<OTHERMULT:MULTIPLIER-31> computed -72 for its part A from pins B, C. 

;|Awakening <ADD:ADDER-23> because its A got the value -72. 

;|<ADD:ADDER-23> computed -40 for its part C from pins A, B. 
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;|Aw a k e nin g <ADD:ADDER-23> because its C got the value -40. 

;(Awakening <0THERMULT:MULTIPLIER-31> because its A got the value -72. 
;(Awakening <MULT:MULTIPLIER-27> because its C got the value -360. 

DONE 


This process of course has computed — 40 for fahrenheit. (See Figure 4-1. As before, circles 
with horizontal bars indicate constant values; in addition, default values arc drawn as plain 
circles.) 

(what fahrenheit) 

;The value -40 in CELL-35 was computed in this way: 

; FAHRENHEIT <- (+ (// (* 9 CENTIGRADE) 5) 32) 

; CENTIGRADE <- -40 
OKAY? 

Now we come to the critical point we left off at in §2.3: what happens if fahrenheit is not 
equated to 32? 

(== fahrenheit (default 32)) 

;;; Contradiction when merging the cells 

; <CELL-35 (FAHRENHEIT): -40> and CCELL-41 (DEFAULT): 32>. 

These are the premises that seem to be at fault: 

; <CELL-40 (DEFAULT): -40> == CENTIGRADE, 

; CCELL-41 (DEFAULT): 32>. 

Choose one of these to retract and RETURN it. 

; BKPT Choose Culprit 
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As before, the system has detected a conflict between the given value and the value previously 
computed for fahrenheit. This time, however, the system has determined the premises of the 
conflicting values and listed them, and asked us to choose which one to retract. (Note that the 
name of a default cell is “def aul t”, not “?”. Similarly, later we shall sec that the name of a 
constant cell is “constant”.) 

Now we are within a “breakpoint”, within which we may interact with the LISP system in the 
usual manner. In particular, we could invoke the why and what functions to explore the network 
before choosing a culprit. 1 When eventually a form ( return form) is typed, then the break¬ 
point level is exited, and the value of form is returned and made available to the program which 
caused the breakpoint. We will do this now: let us choose to retract the value for cent ig rade. 


(return centigrade) 

;|Retracting the premise CCELL-40 (DEFAULT): -40>. 

;|Removing -40 from CELL-40. 

;(Removing -360 from (THE C MULT) because (THE B MULT ) = = CELL-40. 

;jRemoving -72 from (THE A OTHERMULT) because (THE C OTHERMULT)==(THE C MULT). 
;|Removing -40 from (THE C ADD) because (THE A ADD)==(THE A OTHERMULT). 
;|Awakening <ADD:ADDER-23> because its C lost its value. 

;(Awakening <ADD:ADDER-23> because its A lost its value. 

;|Awakening <OTHERMULT:MULTIPLIER-31> because its A lost its value. 

;|Awakening <OTHERMULT:MULTIPLIER-31> because its C lost its value. 

;(Awakening <MULT:MULTIPLIER-27> because its C lost its value. 

;(Awakening <MULT:MULTIPLIER-27> because its B lost its value. 

;|Awakening <ADD:ADDER-23> because its C got the value 32. 

;j<ADD:ADDER-23> computed 0 for its part A from pins B, C. 

;|Awakening <ADD:ADDER-23> because its A got the value 0. 

;(Awakening COTHERMULT:MULTIPLIER-31> because its A got the value 0. 

;|COTHERMULT:MULTIPLIER-31> computed 0 for its part C from pins A, B. 
;|Awakening COTHERMULT:MULTIPLIER-31> because its C got the value 0. 

;(Awakening <MULT:MULTIPLIER-27> because its C got the value 0. 

;|<MULT:MULTIPLIER-27> computed 0 for its part B from pins A, C. 

;|Awakening <MULT:MULTIPLIER-27> because its B got the value 0. 

DONE 


Whew! After the value —40 was retracted for centigrade, all of the values which were 
computed from that value were recursively removed. Then all the constraint devices which had 
values retracted from their pins were awakened, in the hope that they could provide a value for the 


1. This is yet another example of how pleasant it is to implement a toy system by embedding it in a more complete 
system such as LISP. Rather than having the interaction limited to merely a choice from a menu, the user can be 
given the opportunity to perform any computation before making the decision. 
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FIGURH4-2. Recomputution of a Temperature Conversion. 


retracted-from pin. 2 Next the new value 32 for fahrenheit was installed, and the usual process 
of local propagation proceeded from there. T he result is pictured in Figure 4-2. We can ask what 
about the value in f ahrenhe i t. 

(what fahrenheit) 

;The value 32 in CEl.L-35 was computed in this way: 

; FAHRENHEIT <- 32 
OKAY? 

(what centigrade) 

;The value 0 in CELL-36 was computed in this way: 

; CENTIGRADE «- (// (* (- FAHRENHEIT 32) 5) 9) 

; FAHRENHEIT «- 32 
OKAY? 


Everything is just as if we had originally given the value 32 to fahrenheit, and had never given 
the value —-40 to centigrade in the first place. 

When the contradiction occurred above, the computed value for fahrenheit had been 
derived not only from the value for centigrade, but also from the constants 5, 9, and 32. 
However, these constants were not listed among the choices for retraction. T his illustrates the one 
difference between the constant and default constructs—if a contradiction is derived from 
at least one default value, then only default values arc considered for retraction. If the 


2. Presumably this would be the same value that was retracted. However, a constraint device might be an subsidiary 
supplier of the value rather than the primary supplier. When the primary supplier is then retracted, subsidiary 
suppliers then have a chance to become the primary supplier. Thus, rather than recording multiple justifications for 
a value, as in (Stallman 1977J, [Doyle 1978a], [Doyle 1978b], [McAllcstcr 1978], and [Doyle 1979], this system merely 
recomputes value when necessary (presumably involving only a single computation step in each case). 
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Figure: 4-3. Another Rccompulation of a Temperature Conversion. 


contradiction rests solely on constant values, however, then the system will consider retracting a 
constant. 3 To further illustrate die distinction, let us now fix cen t i g rade as the constant 20. 

(== centigrade (constant 20)) 

;;; Contradiction when merging the cells 

; CCELL-36 (CENTIGRADE): 0> and CCELL-42 (CONSTANT): 20>. 

; (Retracting the premise CCELL-41 (DEFAULT): 32>. 

;(Removing 32 from CELL-41. 

;(Removing 0 from (THE A ADD) because (THE C ADD)==CELL-41. 

;(Removing 0 from (THE C OTHERMULT) because (THE A OTHERMULT)==(THE A ADD). 
;(Removing 0 from (THE B MULT) because (THE C MULT) = = (THE C OTHERMULT). 
;(Awakening <MULT:MULTIPLIER-27> because its B lost its value. 

;jAwakening COTHERMULT:MULTIPLIER-31> because its C lost its value. 
;|Awakening <MULT:MULTIPLIER-27> because its C lost its value. 

;|Awakening <ADD:ADDER-23> because its A lost its value. 

;|Awakening COTHERMULT:MULTIPLIER-31> because its A lost its value. 
;|Awakening CADD:ADDER-23> because its C lost its value. 

;|Awakening CMULT:MULTIPLIER-27> because its B got the value 20. 

;|CMULT:MULTIPLIER-27> computed 180 for its part C from pins A, B. 

;(Awakening COTHERMULT:MULTIPLIER-31> because its C got the value 180. 

;(COTHERMULT:MULTIPLIER-31> computed 36 for its part A from pins B, C. 
;|Awakening CADD:ADDER-23> because its A got the value 36. 

;|CADD:ADDER-23> computed 68 for its part C from pins A, B. 

;|Awakening CADD:ADDER-23> because its C got the value 68. 

;|Awakening COTHERMULT:MULTIPLIER-31> because its A got the value 36. 
;|Awakening CMULT:MULTIPLIER-27> because its C got the value 180. 

DONE 


3. One might argue that this should constitute a hard error as before. However, the ability to retract a constant is 
not difficult to provide, and the system can inform the user of the situation and let him decide whether or not to 
tamper with a “constant of the universe”. 
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It doesn’t show clearly here, but in fact the conflict is between the new value 20, a constant, and 
the old value 0, which was derived from various constants and a single default value. The 
system concluded that as there was precisely one default value involved, it might as well retract 
it automatically and not even bother us with it. 

(what fahrenheit) 

;The value 68 in CELL-35 was computed in this way: 

; FAHRENHEIT «- ( + (// (* 9 CENTIGRADE) 5) 32) 

; CENTIGRADE «- 20 
OKAY? 

Now fahrenheit = 68,computed from centigrade = 20 (Figure4-3). 

If we now try to equate fahrenheit to a default value, the system “bounces back”. The 
default value comes into conflict w ith hard constants, and so is immediately rejected. 

(== fahrenheit (default 41)) 

;;; Contradiction when merging the cells 

; CCELL-35 (FAHRENHEIT): 68> and <CELL-43 (DEFAULT): 41>. 

;|Retracting the premise <CELL-43 (DEFAULT): 41>. 

;|Removing 41 from CELL-43. 

DONE 

If we really want fahrenheit to be 41, we had better fight constants with constants! 

(== fahrenheit (constant 41)) 

;;; Contradiction when merging the cells 

; <CELL-35 (FAHRENHEIT): 68> and CCELL-44 (CONSTANT): 41>. 

;;; These are the premises that seem to be at fault: 

; <CELL-44 (CONSTANT): 41>, 

; <CELL-37 (CONSTANT): 32>, 

; <CELL-42 (CONSTANT): 20> == CENTIGRADE, 

; CCELL-39 (CONSTANT): 9>, 

; <CELL-38 (CONSTANT): 5>. 

;;; Choose one of these to retract and RETURN it. 

;BKPT Choose Culprit 

This contradiction involves only constant values, and so one of them must be chosen for retrac¬ 
tion. 

(return centigrade) 

;|Retracting the premise <CELL-42 (CONSTANT): 20>. 

;|Rernoving 20 from CELL-42. 

;(Removing 180 from (THE C MULT) because (THE B MULT) = = CELL-42. 

;(Removing 36 from (THE A OTHERMULT) because (THE C OTHERMULT)==(THE C MULT). 
; (Removing 68 from (THE C ADD) because (THE A ADD)= = (THE A OTHERMULT). 
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;|Awakening <ADD:ADDER-23> because its C lost its value. 

;|Awakening <ADD:ADDER-23> because its A lost its value. 

;|Awakening <OTHERMULT:MULTIPLIER-31> because its A lost its value. 
;|Awakening <OTHERMULT:MULTIPLIER-31> because its C lost its value. 
;|Awakening <MULT:MULTIPLIER-27> because its C lost its value. 

;|Awakening <MULT:MULTIPLIER-27> because its B lost its value. 

;|Awakening <ADD:ADDER-23> because its C got the value 41. 

; |<ADD:ADDER~23> computed 9 for its part A from pins B, C. 

;|Awakening <ADD:ADDER-23> because its A got the value 9. 

;|Awakening <OTHERMULT:MULTIPLIER-31> because its A got the value 9. 

; |<OTHERMULT:MULTIPLIER-31> computed 45 for its part C from pins A, B. 
;|Awakening <OTHERMULT:MULTIPLIER-31> because its C got the value 45. 
;|Awakening <MULT:MULTIPLIER-27> because its C got the value 45. 

; | <MULT:MULTIPLIER-27> computed 5 for its part B from pins A, C. 

;|Awakening <MULT:MULTIPLIER-27> because its B got the value 5. 

DONE 

The constant 20 equated to centigrade lias been retracted, and a new value derived from 
f ahrenhei t. 

(what centigrade) 

;The value 5 in CELL-36 was computed in this way: 

; CENT [GRADE «- (// (* (- FAHRENHEIT 32) 5) 9) 

; FAHRENHEIT «- 41 
OKAY? 


4.1.2. Propagation Potentially Poses Problems for Predefined Pins 

Contradictions can arise not only when equating two nodes, but also when a constraint device 
calculates a value for a pin in conflict with an existing value. As an example of this, consider the 
network of Figure 3-3 (page 92) for constraining four points to be equally spaced. Assume that one 
has been constructed now. 'Then we perform the equatings pi — 0, p3 == 6, and p2 — 4, which 
of course are not consistent. 

(== pi (default 0)) 


;|Awakening <A12:ADDER-89> 

because 

its 

A 

got 

the 

val ue 

0 . 

DONE 








(== p3 (def ault 6)) 








;|Awakening <A34:ADDER-97> 

because 

its 

A 

got 

the 

value 

6. 

;(Awakening <A23:ADDER-93> 

because 

its 

C 

got 

the 

val ue 

6. 


DONE 

So far so good ... 


(== p2 (default 4)) 
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FIGURE 4-4. A Contradiction in a Four-Point Spacing Network. 


;|Awakening <A23:ADDER-93> because its A got the value 4. 

;|<A23:ADDER-93> computed 2 for its part B from pins A, C. 

;|Awakening <A12:ADDER-89> because its B got the value 2. 

;;; Contradiction in <A12:ADDER-89> among these parts: A=0, B = 2, C=4; 

;;; it calculated 2 for A from the others by rule ADDER-RULE-3. 

;;; These are the premises that seem to be at fault: 

; CCELL-101 (DEFAULT): 0> == PI, 

; <CELL-103 (DEFAULT): 4> == P2, 

; <CELL-102 (DEFAULT): 6> == P3. 

;;; Choose one of these to retract and RETURN it. 

This situation is pictured in Figure 4-4. The contradiction was caught when adder al2 computed 
a value for pi which was not consistent with the existing default value. The system has indicated 
that the adder computed the value 2. Of course, the value 0 might be the correct one, and one of 
the premises for p2 or p3 might be at fault. We should examine the computations of all the pins 
involved. 

(what (the a al2)) 

;The value 0 in CELL-90 was computed in this way: 

; (THE A A12) <- 0 
OKAY? 

Actually, in this case we would have preferred that what show us a global name for the constant; 
but it thinks that (the a a 12 ) is the preferred name for the root node because that is what we 
gave it. Fixing this is left as an exercise for the reader. 4 

(what (the b al2)) 

;The value 2 in CELL-91 was computed in this way: 


4. Don’t you just hate it when an author leaves something as an “exercise for the reader”? 
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FIGURH4-5. Defeating Two Defaults in a Four-Point Spacing Network. 


; (THE B A12) <- (- P3 P2) 

; P3 «- 6 

; P2 <- 4 

OKAY? 

Now, this tells us something: (the b a 12 ) is the difference between p3 and p2. 

(what (the c al2)) 

;The value 4 in CELL-92 was computed in this way: 

; (THE C A12) <- 4 
OKAY? 

We could choose to retract any of the premises; let us in fact choose pi. 

(return pi) 

;|Retracting the premise <CELL-101 (DEFAULT): 0>. 

;|Awakening <A12:ADDER-89> because its C got the value 4. 

DONE 

(Much of the tedious trace output has been omitted here; sixteen lines were deleted. Flcnceforth 
most c t race output will be similarly condensed, and omissions indicated by ellipses.) 

(what pi) 

;The value 2 in CELL-85 was computed in this way: 

; PI <- (- P2 (- P3 P2)) 

: P2 4 

: P3 ♦- 6 

OKAY? 

(what p4) 

;The value 8 in CELL-88 was computed in this way: 

; P4 <- (+ P3 (- P3 P2)) 
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Figure. 4-6. Redunchuit Premises for a Four-Point Spacing Network. 


; P3 «- 6 
; P2 «- 4 
OKAY? 

New values for p 1 and p4 have been computed in terms of p2 and p3. (See Figure 4-5.) 

Multiple contradictions can arise in a single interaction, if the network contains redundant 
reasons for current values. For example, in a fresh four-point-spacing network, this might occur: 

(== pi (default 1)) 

;|Awakening <A12:ADDER-69> because its A got the value 1. 

DONE 

(== p3 (default 5)) 

DONE 

(== p2 (default 3)) 

DONE 

The three values for pi, p2, and p3 constitute redundant information for the network. Given 
pi and p2, p3 could have been deduced; given p2 and p3, pi could have been deduced. 
(However, p2 was not deduced given pi and p3 because that cannot be done by local propaga¬ 
tion; algebra is required. Once a correct value for p2 was supplied, however, the system verified 
it.) 


(what p4) 

;The value 7 in CELL-68 was computed in this way: 
; P4 «- (+ P3 (- P3 P2)) 

; P3 <- 5 
; P2 *- 3 
OKAY? 
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The value 7 was computed for p4 (Figure 4-6). If now p4 is equated to 6, a contradiction must 
occur. 

(== p4 (default 6)) 


Contradiction when merging the cells 

<CELL-68 (P4): 7> and <CELL-84 (DEFAULT): 6>. 
These are the premises that seem to be at fault: 


<CELL-82 

(DEFAULT) : 

5> 

<CELL-83 

(DEFAULT) : 

3> 

CCELL-84 

(DEFAULT): 

6>. 


Choose one of these to retract and RETURN it. 


Indeed, as what indicated, the old value of p4 depended on p2 and p3. We choose to retract 

P2. 


(return p2) 

;|Retracting the premise <CELL-83 (DEFAULT): 3>. 

;(Removing 3 from CELL-83. 

;(Removing 2 from (THE B A23) because (THE A A23)==CELL-83. 

; (Removing 7 from (THE C A34) because (THE B A34) = = (THE B A23). 

;|Awakening <A34:ADDER-77> because its C lost its value. 

;|Awakening <A34:ADDER-77> because its C got the value 6. 

;|<A34:ADDER-77> computed 1 for its part B from pins A, C. 

; (Awakening <A12:ADDER-69> because its B got the value 1. 

;(<A12:ADDER-69> computed 2 for its part C from pins A, B. 

;|Awakening <A23:ADDER-73> because its A got the value 2. 

;;; Contradiction in <A23:ADDER-73> among these parts: A = 2, B=l, C = 5; 

;;; it calculated 4 for A from the others by rule ADDER-RULE-3. 

;;; These are the premises that seem to be at fault: 

; <CELL-81 (DEFAULT): 1> == PI, 

; <CELL-82 (DEFAULT): 5> == P3, 

; <CELL-84 (DEFAULT): 6> == P4. 

;;; Choose one of these to retract and RETURN it. 

While p2 supported the value for p4, the redundant value in pi also supported it indirectly, and 
now the computation has run afoul again. The system is not satisfied until the network is totally 
consistent. Wc could now change our minds and retract the assignment of 6 to p4, but here we will 
proceed to retract pi. 

(return pi) 

;|Retracting the premise <CELL-81 (DEFAULT): 1>. 

;(Removing 1 from CELL-81. 

;(Removing 1 from (THE B A12) because (THE A A12)==CELL-81. 

; (Removing 2 from (THE C A12) because NIL = = (THE B A12). 
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;(Awakening <A23:ADDER-73> because its A lost its value. 

;(Awakening <A34:ADDER-77> because its B got the value 1. 
DONE 

The end result is pictured in Figure 4-7. 


4.1.3. Erroneous Fquatings Elicit Execution Exceptions Equally Easily 

Until now it has been implicitly assumed that the constraint network, once constructed, is 
fixed. All computations are relative to this fixed structure, and any errors arc attributed to the 
chosen premises rather than to the network structure. Premises can be retracted, but not connec¬ 
tions. The retraction mechanism exhibited above operates not by disconnecting a rejected constant 
cell from the rest of the network, but by “denaturing” the constant, forcibly removing its value but 
leaving it connected as a useless appendage (useless because it has no value and no name). 

Mere are introduced two functions dissolve and disconnect for undoing connections. 
When given a cell, dissolve will undo the connections among all the cells of the node to which 
the given cell belongs. On the other hand, disconnect causes a specified cell to be unhooked 
from its node, leaving any others connected together. Neither of these is a true inverse for the = = 
construction; for example, if one says (== a b) and then (disconnect a), the new situation 
will be identical to the original only if a had not previously been connected to any other cells. If it 
had, then those cells will now all be connected to b . It is impossible to provide a way to provide 
a true inverse for == given the current data structures used in the implementation, because not 
enough information is retained (for example, no information whatever is recorded for redundant 
cquatings). Eater we will sec ways of providing for this. 
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To illustrate the use of dissolve and disconnect, consider yet another fresh four-point 
spacing network. Initially p4 has no value, and can be expressed in terms of pi, p2, and p3. 

(what p4) 

;CELL-92 has no value. I can express it in this way: 

; P4 = (+ P3 (- P2 PI}) 

OKAY? 

If the connection between the b pins of the three adders is now dissolved, then of course p4 can 
no longer be expressed in terms of the difference between p2 and pi. 

(dissolve (the b al2)) 

; |Dissolving (THE B A12), (THE B A23), (THE B A34). 

DONE 

See Figure 4-8. 

(what p4) 

;CELL-92 has no value. I can express it in this way: 

; P4 = (+ P3 (THE B A34)) 

OKAY? 

If now a default value is given to (the b a 12), it will not affect (the b a23) be¬ 
cause they arc no longer connected. 

(== (the b al2) (default 3)) 

;|Awakening <A12:ADDER-93> because its B got the value 3. 

DONE 

(what (the b a23)) 

;CELL-99 has no value. I can express it in this way: 

; (THE B A23) = (- P3 P2) 

OKAY? 




118 Chapter Four 


RLi FRACTION 



Let us now also equate (the b a23) to 3, and pi to 0. This will result in the computation 
of 3 for p2 and 6 for p3. 

(== (the b a23) (default 3)) 

;|Awakening <A23: ADDER-97> because its B got the value 3. 

DONE 

( = = pi (default 0)) 

; |Awakening <A12:ADDER-93> because its A got the value 0. 

DONE 

The result is shown in Figure 4-9. 

(what p3) 

;The value 6 in CELL-91 was computed in this way: 

; P3 «- (+ (+ PI 3) 3) 

; PI *- 0 
OKAY? 

(what p4) 

;CELL-92 has no value. I can express it in this way: 

; P4 = (+ 6 (THE B A34)) 

OKAY? 


No value was computed for p4 because ( the b a34) still has no value. Suppose we were 
to connect (the b a34) to p2 (which produces something other than a four-point spacing 
network!). 

(== (the b a34) p2) 

;|Awakening <A34: ADDER-101> because its B got the value 3. 

;|<A34:ADDER-101> computed 9 for its part C from pins A, B. 





§4.1.3 


Forgiving Systems 119 



;|Awakening <A34:ADDER-101> because its C got the value 9. 

DONE 

See Figure 4-10. 

(what p4) 

;The value 9 in CELL-92 was computed in this way: 

; P4 <- (+ (+ P2 3) P2) 

; P2 *- (+ PI 3) 

; PI <- 0 

OKAY? 

Now P4 has the value 9 expected for equal spacing, but that value was computed in a rather 
unorthodox fashion! Let us undo the connection. 

(disconnect (the b a34)) 

;(Disconnecting (THE B A34) from (THE A A23), (THE C A12), P2. 

;(Removing 3 from (THE B A34). 

;(Removing 9 from (THE C A34) because of NIL. 

;|Awakening <A34:ADDER-101> because its C lost its value. 

;|Awakeninq <A34:ADDER-101> because its B lost its value. 

DONE 

When (the b a34) was disconnected from the p2 node, it was disconnected from the source 
of its value. Hence the value 3 was removed from it. and thus the value 9 derived from it was also 
removed from (the c a34) = = p4. The network has now been restored to the situation of Figure 
4-9. 

(== (the b a34) (the b a23)) 
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P3 


P4 



Figure: 4-11. A Usefully Modified Four-Point Spacing Network. 


;|Awakening <A34:ADDER-101> because its B got the value 3. 

;|<A34:ADDER-101> computed 9 for its part C from pins A, B. 

; (Awakening <A34: ADDF.R-101> because its C got the value 9. 

DONE 

Now (the b a34) has been connected to a more legitimate source of 3. 'This network makes 
some sense: it spaces p2, p3, and p4 equally, and allows a different spacing to be specified 
between pi and p2. Thus the disconnection facility can be used to make useful modifications to 
an existing network. 

Disconnecting (the b al2) will sever the connection with the default value 3. This will 
cause retraction of many computed values. 

(disconnect (the b al2)) 

; |Disconnecting (THE B A12) from CELL-105. 

;|Removing 3 from (THE B A12). 

;|Removing 3 from (THE C A12) because of NIL. 

; (Removing 6 from (THE C A23) because (THE A A23) = = (THE C A12). 

; (Removing 9 from (THE C A34) because (THE A A34) = = (THE C A23). 

;|Awakening <A34:ADDER-101> because its C lost its value. 

DONE 

This situation is shown in Figure 4-11. 

If now (the b al2) and (the b a23) are connected, the spacing network will have 
been completely restored, and p4 can be computed from pi = 0 and the given spacing 3. 


( = = (the b al2) (the b a23)) 
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Figurj-; 4-12. A Usefully Modified Four-Point Spacing Network. 


DONE 

(what p4) 

;The value 9 in CELL-92 was computed in this way: 
; P4 <- ( + (+ (+ PI 3) 3) 3) 

: PI <- 0 

OKAY? 

This final happy circumstance appears in Figure 4-12. 


4.2. Implementation of Retraction Mechanisms 

The primary visible difference in the language, aside from the addition of extra capabilities 
such as dissolve, is the new distinction between default and constant values. Internally 
they arc the same, except that each cell is tagged as to which type it is, for those routines which care 
to check for die distinction. 

The changes for constant, default, constantp, and globalp appear in Table 4-1. 
The function formerly called cons tan t has been renamed initial i zed-cel 1, and given an 
extra parameter reason, which will be the symbol constant or default. The functions of 
those names simply call initial ized-cell. When the cell is generated by gen-cell, the 
name given to the cell is not “ ? ” as before, but rather the symbol constant or default; 
this was originally intended to make the distinction visible when such a cell is printed, but turned 
out to have an important application in the retraction process. The predicates constantp and 
globalp, which operate by checking the name of the cell, require changes for the new naming 
convention. Finally, recall that the rule component of a node was formerly only used if the supplier 




122 Chapter Four 


Rhtraction 


(defun constant (value) 

J (initialized-cel1 value 'constant)) 

(defun default (value) 

(initialized-cel1 value 'default)) 

(defun in itial ized-cel1 (value reason) 

(let ((cell (gen-cell reason))) 

(setf (node-contents cell) value) 

(setf (node-boundp cell) t) 

(setf (node-supplier cell) cell) 

| (setf (node-rule cell) reason) 
cell)) 

(defun constantp (cell) 

(require-cell cell) 

| (and (null (cell-owner cell)) (niemq (cell-name cell) '(constant default)))) 

(defun globalp (cel 1) 

(require-ce11 cell) 

j (and (null (cell-owner cell)) (not (memq (cell-name cell) '(constant default))))) 

Compare this with Table 3-2 (page 76). 

Tabu: 4-1. Implementation of Constant and Default Cells. 


for the node was a pin, because if the supplier was a constant then the “rule” for the value was self- 
evident. Now, when the supplier is a constant or defaul t cell, which kind is recorded as the 
rule. (This information could still be derived from the cell name, but it seems cleaner to express it 
as the rule.) 

The handling of contradictions must be changed to allow for retraction. Contradiction han¬ 
dling is now centralized in the function process-contradiction. The function merge-values 
is changed to call process-contradiction on discovering a conflict (after printing a 
message). However, this is no longer considered to be a fatal error that brings the system to 
a grinding halt. It is assumed that process-contradiction may have fixed the problem 
(but only maybe!—if the conflicting values depended on redundant premises, then removing one 
premise may only have caused the retraction and rccomputation of the conflicting value from other 
premises). Thus, when process-contradict ion returns, the merge must be retried. 

If a merge discovers a contradiction, then die resolution of that contradiction will require 
changing the values of the cells involved. Hence it is important in == not to decide which of the 
cells is bound until after merge-values has been called. (This is a subtle interaction which I 
missed at first!) Thus = = has been rearranged to call merge-values first thing, and save the 
result in newval. Also, the decision as to which repository to use (and thus which cell of die 
merged node should become the supplier) has become more complicated: as a heuristic, if one 
supplier is a constant (as determined by looking at the rule), then that is preferred to anything 
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(defun == (celll cell2) 

(require-cel1 celll) 

(require-cel 1 cell2) 

(or (eq (cel 1 - repository celll) (cel 1-repository ce112)) 

| (let ((newval (merge-values celll cel!2))) 

(let ((rl (cel 1-repository celll)) 

(r2 (cel 1-repository ce112)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp cel 12))) 

(lei ((r (cond ((eq (rep-rule rl) 'constant) rl) 

((eq (rep-rule r2) 'constant) r2) 

((or (not cb2) (and cbl (ancestor celll cell2))) rl) 
(t r2 ) )) 

(rcells (append (rep-cells rl) (rep-cells r2)))) 

| (setf (rep-contents r) newval) 

(let ((newcomers (if cbl (if cb2 '() (rep-cells r2)) 

(if cb2 (rep-cells rl) '())))) 

(setf (rep-cells r) rcells) 

(dolist (cell (rep-cells (if (eq r rl) r2 rl))) 

(setf (ce11-repository cell) r)) 

(awaken-all newcomers) 

'done)))))) 

(defun merge-values (celll cell2) 

(require-cel 1 celll) 

(require-cel 1 cell2) 

(let ((vail (node-contents celll)) 

(val2 (node-contents cell2))) 

(cond ((not (node-boundp celll)) val2) 

((not (node-boundp cel!2)) vail) 

((equal vail val2) vail) 

(t (ctrace "Contradiction when merging ~S and ~S." celll cell2) 
(process-contradiction (list celll cell2)) 

(merge-values celll cel!2))))) 

(defun awaken-all (cells) 

(dolist (cell cells) 

(require-cel 1 cell) 

(cond ((cell-owner cell) 

(ctrace "Awakening ~S because its ~S 

~:[lost its value~*~;got the value ~S~]." 

(cell-owner cell) 

(cell-name cell) 

(node-boundp cell) 

(node-contents cell)) 

(awaken (cell-owner cell)))))) 

Compare this with Table 3-3 (page 77). 

Tahlh 4-2. Delaying Equating Decisions Until after the Merge. 


else. This cannot cause circularities, because nothing is an ancestor of a constant. The reason for 
this heuristic will be discussed below. 
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(defmacro setc {cellname value) 

‘(process-setc *me* cellname ,(symbol cone cellname "-CELL") ,value *rule*)) 

(defun process-setc (*me* name cell value rule) 

(require-constraint *me*) 

(require-cel1 cell) 

(let ((sources (get rule 'trigger-names))) 

(cond ((not (node-boundp cell)) 

(ctrace "~S computed ~S for its part ~S~:[~2*~; from pin~P ~{~S~t, 
*me* value name sources (length sources) sources) 

(setf (node-contents cell) value) 

(setf (node-boundp cell) t) 

(setf (node-supplier cell) cell) 

(setf (node-rule cell) rule) 

(awaken-all (node-cells cell))) 

((not (equal (node-contents cell) value)) 

(let ((triggers (forlist (pinname sources) (*the pinname *me*)))) 
(ctrace "Contradiction in ~S~@[ among these parts: ~ 

~°/°;| it calculated ~S for ~S 

from the others by rule ~S." 

*me* 

(forlist (cell (cons cell triggers)) 

(require-cel 1 cell) 

(list (cell-name cell) (node-contents cell))) 
value 

(cell-name cel 1) 
rule) 

(process-contradiction (cons cell triggers)) 

(do ((x triggers (edr x))) 

((null x) (process-setc *me* name cell value rule)) 

(or (node-boundp (car x)) (return)))))))) 

Compare this with fable 3-8 (page 82). 

Table4-3. Handling Contradictions in setc. 


The ctrace message printed by awaken-all is changed because owners may now be 
awakened not only because a pin has newly received a value, but because a pin has lost a value (in 
which case the awakening is a request to recompute it if possible). 
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(defmacro contradiction vars 

‘(signal-contradiction (list ,@(forlist (v vars) (symbol cone v "-CELL"))) *me*)) 

(defun signal-contradict ion (cells constraint) 

(require-constraint constraint) 

| (ctrace "Contradiction in ~S~@[ among these parts: ~:{~S=~S~:t, 
constraint 

(forlist (cell cells) 

(require-cel1 cell) 

(list (cell-name cell) (node-contents cell)))) 

| (process-contradiction cells)) 

(defun process-contradiction (cells) 

(let ((premises (premises* cells))) 

(let ((losers (do ((p premises (edr p)) 

(z '() (if (eq (node-rule (car p)) 'default) 

(cons (car p) z) 

z))) 

((null p) (or z premises))))) 

(cond ((null losers) (lose "Hard-core contradiction!")) 

((nul1 (edr losers)) 

(retract (car losers))) 

(t (retract (choose-culprit losers))))))) 

(defun choose-culprit (losers) 

(format t These are the premises that seem to be at fault:~ 

~:{~"/o;~8X~S~@{ == 

(forlist (p losers) 

(cons p (mapean #'(lambda (c) 

(and (globalp c) 

(list (cell-name c)))) 

(node-cells p))))) 

(format t "~ 1 \;; Choose one of these to retract and RETURN it.") 

(let ((culprit (break "Choose Culprit"))) 

(do ((z losers (edr z))) 

((null z) (choose-culprit losers)) 

(and (eq (cell-repository (car z)) (cell-repository culprit)) 

(return (car 7 )))))) 

Compare this with Table 2-11 (page 57). 

Table 4-4. Processing and Recovering from Contradictions. 


The processing for the setc construct remains the same in the usual case (see Table 4-3). 
When a contradiction is detected, however, because the value computed by a constraint conflicts 
with a value already on the pin, then process-contradiction is called, giving it a list of 
the conflicting cells. When process-contradict ion returns, then there is a question as to 
whether to instill the value in the pin after all—the processing of the contradiction may have 
removed the support for that value. Hence process-setc checks all of the trigger pins for the 
rule, and only retries the setc operation if they all still have values. 
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( r rhcrc are serious problems remaining, however. The assumption here is that no new values 
will be asserted within process-contradiction, but only old ones retracted. This requires 
the assumption that the user will not assert new equatings within the breakpoint provided by 
signal-contradiction, but only use probing functions like what. If the user were to not 
simply retract a value from a trigger pin but were also to provide a new value, then the test in 
process-setc would be incorrect; a value would be supported, but not the one in hand! A 
better thing to do would be to restart the rule which invoked setc; this involves a non-local 
escape. This issue will be addressed in the next chapter.) 

The contradiction construct is implemented in the same way as before (Table 4-4). 
The function signal-contradiction does not signal a fatal error, however, but simply 
prints a message and then calls process-contradict ion. 5 This function takes a list of 
conflicting cells, All of the places in the system which detect contradictions (merge-val ues, 
process-setc, and contradiction) handle them by calling process-cont rad ict i on. 

A set of “losers” (constant cells deemed to be collectively at fault for the contradiction) is 
computed. The function premises* computes the set of joint premises for the list of cells. Then 
those premises which are def aul t cells are extracted. If there are any default cells, then those 
arc considered to be the losers; otherwise all the premises (which must then all be constant 
cells) are taken as the losers. If there are no losers at all (this shouldn’t ever happen?), it is fatal. 
If there is just one loser, it is automatically retracted. Otherwise, choose-cul pri t is called to 
decide which one to retract. 

(Suppose there arc two losers, and one is a default node specified explicitly in a == re¬ 
quest which the user just typed, causing the contradiction. Should the system in this case automati¬ 
cally retract the value just specified (thus making the network resistant to obvious inconsistent 
changes)? This would make it hard to vary parameters. Or should the system automatically retract 
the other loser, allowing the one just explicitly specified to hold? Consider the two cases where the 
cell to which the default was explicitly equated already had a value or did not. Kxcrcise for the 
reader: determine what is “the right thing”.) 

In principle, choose-culprit could be an automatic routine using various heuristics to 
decide which loser to retract. T his version defers the problem to the user (not necessarily the best 
thing to do). It prints the list of losers (for each one printing also any global names connected to it), 
and then calls break to enter a lisp breakpoint. The return function causes the specified value 
to be returned from the call to break, so this is bound to the variable culprit . This returned 
value is then tested to ensure that it is a valid culprit; if it is not, then the question is repeated. 
The user need not return an actual loser cell, but may return any cell of that node. This is for 
convenience, so that the user may refer to a value by an equivalent global name. 


5. As with setc, there is an assumption that within process-contradiction there will be only retractions, not 
any newly computed values. lTierefore it is not necessary to retry the contradiction test. 
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(defun retract (cell) 

(ctrace "Retracting the premise ~S." cell) 

(awaken-all (forget cell))) 

(defun forget (cell &optional (source () sourcep) (via () viap)) 

(require-cel 1 cell) 

(and sourcep (require-ce11 source)) 

(and viap (require-cel 1 via)) 

(ctrace "Removing ~S from ~S~:[~3*~; because ~:[of ~;~S==~]~S~]." 
(node-contents cell) 

(cell-goodname cell) 
sourcep 

(and viap (not (eq via source))) 

(and viap (not (eq via source)) (cel 1-goodname via)) 

(and sourcep (cel 1 -goodname source))) 

(setf (node-boundp cell) ()) 

(setf (node-contents cell) ()) 

(setf (node-supplier cell) ()) 

(setf (node-rule cell) ()) 

(let ((fcells (append (rep-cells (cel 1-repository cell)) '()))) 

(dolist (c (rep-cells (cel 1-repository cell))) 

(and (cell-owner c) 

(dolist (value (con-values (cell-owner c))) 

(require-cel I value) 

(and (node-boundp value) 

(eq value (node-supplier value)) 

(memq (cell-name c) 

(get (node-rule value) 'trigger-names)) 

(setq fcells (nconc (forget value cell c) fcells)))))) 

feel Is)) 

Tablh 4-5. Retracting Values from the Network. 


(defun premises (cell) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) '()) 

(t (let ((s (node-supplier cell))) 

(if (null (cell-owner s)) 

(list s) 

(premises* (forlist (name (get (node-rule s) 'trigger-names)) 
(♦the name (cell-owner s))))))))) 

(defun premises* (cells) 

(do ((c cells (edr c)) 

(p '() (unionq (premises (car c)) p))) 

((null c) p))) 

Compare this with Table 3-10 (page 84). 

Tabi. li 4-6. A Rewriting of the premises Function. 


The function retract in fable 4-5 takes care of removing the value from a cell and awaken¬ 
ing the relevant constraints to request rccomputation. The recursive function forget takes a cell 
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whose value should be removed and returns a list of cells whose owners should be awakened. ( ITie 
optional arguments source and via are used only internally to produce better ctrace output, 
so that the chain of recursive forgetting is more easily followed.) 

Once the ctrace output has been produced in forget, the value is removed from the 
repository and die boundp, supplier, and rule components reset. Then the variable feel Is is 
used to accumulate a set of cells whose owners should be awakened. This is initially all the cells 
of the current node. In addition, if any cell of the current node has an owner, and any of the pins 
of that owner was computed by a rule using that cell as a trigger, then those pins must also be 
forgotten, and the set of cells returned by the recursive call to forget is added to the current 
feel Is set. Finally the complete feel Is list is returned. (The nconc function can be used 
instead of the set-union operation unionq because we know that any node can be forgotten at 
most once; if such a node is encountered again by another path, its cells will not be returned by 
forget . A 1.ISP trick: the call to append in the initialization of feel Is copies the list of cells 
so that nconc may be used later and not destroy the list used by the repository.) 

In summary, forget removes the value from the given node and all nodes whose values 
recursively depend on it. All the cells of all the nodes which lost values are returned. The owners 
of these cells must be awakened; this process is known as “begging”, because a node that forgets its 
value must beg connected devices to re-supply (and re-support) die value. This is necessary because 
the device might, after all, have provided a value as a subsidiary supplier, only to have the value 
discarded because it agreed with the value provided by the main supplier. 

The function premises*, which is simply a part of premises which formerly was not 
a separate function, is given in Table 4-6. This illustrates a common situation in dealing with 
recursive data structures: one part of the recursion involves mapping over a list of sub-structures. 
Writing two mutually recursive functions allows two entry points, one taking a single structure, 
one taking a list of them. A similar transformation for fast-premises (which the reader will 
recall docs the same thing as premises, but with a better worst case, by using graph-marking 
techniques) appears in fable 4-7. 

Counterintuitively, it is actually easier to dissolve a node than to disconnect a single cell from 
a node. One might think that dissolution involves more work, and indeed it may; but disconnecting 
requires more special eases, because one cell is treated differently from the rest, and so requires 
more code. 

When a node is dissolved (see the code for dissolve in fable 4-8), each cell must become 
a node unto itself, and so each must have its own repository. To avoid some work and to avoid 
wasting a repository, the existing repository is left attached to the supplier for the original node. If 
the node has no value, then an artificial supplier is chosen arbitrarily by using the cell received as 
an argument. For every cell other than the supplier, a repository is created and hooked up to the 
cell. If the cell is a constant (in which case the node must have a value, and that value must be the 
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(defun fast-premises (cell) 

(require-cell cell) 

(proyl (fast-premises-mark cell) (fast-premises-unmark cell))) 

(defun fast-premises* (cells) 

(progl (fast-premises-mark* cells) (fast-premises-unmark* cells))) 

(defun fast-premises-mark (cell) 

(require-cel 1 cell) 

(and (node-boundp cell) 

(let ((s (node-supplier cell))) 

(cond ((markp s) '()) 

(t (mark-node s) 

(if (null (cell-owner s)) 

(list s) 

(f as t-premises-mark* 

(forlist (name (get (node-rule s) 'trigger-names)) 
(*the name (cell-owner s)))))))))) 

(defun fast-premises-mark* (cells) 

(do ((c ce l 1s (cdr c)) 

(p '() (nconc (fast-premises-mark (car c)) p))) 

((null c) p))) 

(defun fast-premises-unmark (cell) 

(require-cel 1 cel 1) 

(let ((s (node-supplier cell))) 

(cond ((markp s) 

(unmark-node s) 

(or (null (cell-owner s)) 

(f ast-premises-unmark 

(forlist (trigger-name (get (node-rule s) 'trigger-names)) 
(*the trigger-name (cell-owner s))))))))) 

(defun fast-premises-unmark* (cells) 

(dolist (cell cells) (fast-premises-unmark cell))) 

Compare this with Table 3-11 (page 85). 

Tabu: 4-7. A Rewriting of the fast-premises Function. 


constant’s value, even though the constant is not the supplier—the assumption is that the network 
is consistent), then the new repository should bear the value. The constant cell becomes its own 
supplier, and the name of the cell (constant or default) is used as the rule name. (This is the 
situation alluded to earlier where the cell name is used other than for printing.) If the cell is not a 
constant, then it becomes a valueless node, as it has become disconnected from its supplier (if any). 

Once each cell has gotten its own repository, then the original repository remains with the 
supplier cell alone; its cells component is updated to reflect this fact. 

Finally, if the node had had a value, then disconnecting some cells has the effect of retraction 
of a value, and so the forget function must be applied. Hvcry ceil which is not bound and has an 
owner is given to forget to recursively remove values which depended on the connection; once 
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(defun dissolve (cell) 

(require-cel1 cell) 

(let ((supplier (if (node-boundp cell) (node-supplier cell) cell)) 

(cells (node-cells cell))) 

(ctrace "Dissolving ." (forlist (c cells) (cel 1-goodname c))) 

(dolist (c cells) 

(or (eq c supplier) 

(let ((r (make-repository))) 

(cond ((and (node-boundp supplier) (constantp c)) 

(setf (rep-contents r) (node-contents supplier)) 

(setf (rep-boundp r) t) 

(setf (rep-supplier r) c) 

(setf (rep-rule r) (cell-name c)))) 

(setf (cel 1-repository c) r) 

(push c (rep-cells r))))) 

(setf (node-cells supplier) (list supplier)) 

(and (node-boundp supplier) 

(let ((queue '())) 

(dolist (c cells) 

(cond ((and (not (node-boundp c)) (cell-owner c)) 

(setf (node-contents c) (node-contents supplier)) ;kludge 

(setq queue (nconc (forget c) queue))))) 

(awaken-all queue)))) 

' done) 

Table 4-8. Dissolving a Node—Carefully!. 


this has been done, all the appropriate awakenings are performed. (The line marked “kludge” puts 
the old value back into the repository solely so that forget can print its trace message correctly 
before removing the value again.) 

Observe that di ssol ve works correctly in the limiting case of a single-cell node. The first 
loop does nothing; the setting of the node-cells changes nothing; and the second loop only executes 
when the supplier has a value, but its body only works for cells with no value. Hence the node 
remains effectively unchanged. 

Disconnecting a cell requires some special cases ('fable 4-9). T he disconnected cell must ac¬ 
quire a new repository, while the old one remains with all the other cells of the node. The cell 
is deleted from the cells list of the old repository, and hooked up to the new one. The contents, 
boundp, supplier, and rule components arc copied from the old repository to the new one. There 
follow several cases. 

(a) If the node had had a value and was the supplier for the node, then there is great upheaval. 
F’irst there is a search for other cells of the node which might immediately become a new 
supplier for the node; such cells must be constants. However, constant cells arc preferred 
to defaul t cells, and so there are two identical loops, one looking for constant cells, and 
the other for default cells if the first one fails. In either case, the found cell is installed as the 
new supplier. If no such new supplier can be found, then a third loop applies forget to all 
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(defun disconnect (cell) 

(require-cel 1 cell) 

(let ((oldr (cell-repository cell)) 

(newr (make-repository))) 

(setf (rep-cells oldr) (delq cell (rep-cells oldr))) 

(ctrace "Disconnecting ~S from 
(cel 1-goodname cell) 

(forlist (c (rep-cells oldr)) (cel 1-goodname c))) 

(setf (cel 1-repository cell) newr) 

(push cell (rep-cells newr)) 

(setf (rep-contents newr) (rep-contents oldr)) 

(setf (rep-boundp newr) (rep-boundp oldr)) 

(setf (rep-supplier newr) (rep-supplier oldr)) 

(setf (rep-rule newr) (rep-rule oldr)) 

(cond ((and (rep-boundp oldr) (eq cell (rep-supplier oldr))) 

(do ((c (rep-cells oldr) (cdr c))) 

((null c) 

(do ((cc (rep-cells oldr) (cdr cc))) 

((null cc) 

(do ((ccc (rep-cells oldr) (cdr ccc)) 

(z '() (nconc (forget (car ccc)) z))) 

((null ccc) (awaken-all z)))) 

(cond ((and (constantp (car cc)) 

(eq (cell-name (car cc)) 'default)) 

(ctrace "~S becomes the new supplier for the node." 

(cel 1-id (car cc))) 

(setf (rep-supplier oldr) (car cc)) 

(return))))) 

(cond ((and (constantp (car c)) 

(eq (cell-name (car c)) 'constant)) 

(ctrace "~S becomes the new supplier for the node." 

(cell-id (car c))) 

(setf (rep-supplier oldr) (car c)) 

(return))))) 

((cons tan tp cell) 

(setf (rep-supplier newr) cell) 

(setf (rep-rule newr) (cell-name cell))) 

(t (awaken-all (forget cell))))) 

' done) 

Table 4-9. Disconnecting a Cell from a Node. 


of the cells of the node, and then gives the collective nodes to awaken-al 1 in an attempt to 
recompute a value. 

(b) If the cell had been a constant but not the supplier for the node, then its value must have been 
the same as that of the node. It retains its value, but becomes its own supplier again, and the 
rule is copied from the cell name (constant or default), just as for dissolve in fable 
4-8. 

(c) Otherwise the cell has been disconnected from its supplier, and its value must be forgotten. 
The usual forget-awaken-al1 sequence is applied to it. 
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4.3. Summary of the Retraction Mechanisms 

The retraction capability exhibits the first traces of an automatic deduction facility. When a 
contradiction is observed, the system automatically traces the problem to its origin, and then makes 
a decision (sometimes automatically, but often by asking the user) as to how to solve the problem. 
Once the decision is made, the system will remove one premise from the network and “anti¬ 
propagate’' the value—that is, propagate the removal by removing values which were computed 
from it, and then try to find ways to recompute removed values. Thus the system tries in whatever 
way it can to compute values for as many nodes as possible. 

The distinction introduced between constant and defaul t cells allows the user to ex¬ 
press a level of confidence in the value. For example, constants used within a program that are part 
of the intended algorithmic structure can be expressed as constant cells, while input data can be 
expressed as defaul t cells. The distinction is used to decide what premises to retract in case of 
contradiction. As a secondary benefit, the distinction can also be used to choose hcuristically the 
“best” supplier for a node. In the general case one might want to have many types of constant cells, 
with some partial order among the types to determine which ones arc losers; even more generally, 
a user procedure could be allowed to step in and choose among the premises; but this gets very 
complicated. 

The ability to disconnect portions of the computation network also is a kind of retraction 
capability. When a computation goes awry, the fault may be with the input data, but it may also be 
that the program was misconstructed. However, we have not yet provided for automatic retraction 
of network connections! Such a facility might be useful, however—certainly the network is suspect 
if a contradiction cannot be traced to any premise! If constant cells are considered to be part of 
the algorithmic structure expressed by the network., then perhaps suspicion of network connections 
should be on a par with suspicion of constant values. 

The default mechanism is not quite like that in [Doyle 1978a] and [McAllcstcr 1978]; it 
gives preference to the value for retraction, but makes no attempt to rc-asscrt the value if the 
situation causing the contradiction is altered. This ability is treated in the next chapter. 



Once you were two. 

Dear birthday friend. 

In spite of purple weather. 

But now you are three 
And near the end 
As we grewsome together. 

How fourthful thou. 

Forsooth for you. 

For soon you will be more! 

But—fore 

One can be three be two; 
Before be Jive before! 

—Walt Kelly (1951) 
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DKi'AUl.T VALUliML-C1IANISM presented in Chapter Four allows one to say, “in the ab- 
Jl_ sence of any other information, assume that a certain value is thus-and-so—but feel free 
to ignore the value if necessary.” In our constraint language, however, where computations can 
be undone and redone , it is useful to draw a distinction between a default value which, once 
retracted, docs not rc-appcar, and one which has a certain persistence. We will call the latter kind 
an assumption. 

There arc applications for constraints where it is vital that a node always have some value. For 
example, if a node represents the x-position of some graphical object being displayed on a screen, 
then if the object is to appear it must have some x-position. An assumption might be that the x* 
position is zero unless otherwise constrained. 

Another use of assumptions is in case analysis. If it is known (or assumed!) that a node must 
take on one of a specific set of values, then one element of that set can be arbitrarily assumed to be 
the value of the node; another can always be chosen if this leads to a contradiction. Such assump¬ 
tions lead to conclusions which arc permissible, rather than required. If, however, one goes a step 
further and arranges to assume all of the values, one by one, then any conclusions which come out 
the same for all the choices must be the case independent of the choice, leading to the deduction 
that such conclusions arc required independent of the choice of value for the node. (Here we shall 
not make use of this extra step, but will make use of its contrapositive form: if every assumption of 
a set leads to a contradiction, then the choice from the set is not itself at fault for the contradiction, 
but rather the sets of other premises for the respccitive contradictions, taken collectively. This will 
lead to the resolution principle.) 
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5.1. Definition of Assumption Constructs 

Wc will introduce two new constructs to the language: assume and oneof. Kach one will 
represent a cell in the same manner that the constant and defaul t constructs do. However, 
assume and oneof cells will have an associated mechanism for persistently giving the cell a 
value. 

More precisely, (assume n) should generate a cell which has the value /; provided that 
the cell can take on that value consistently with the rest of the network. If having the value n 
would conflict with constan t or def aul t values in the network, then the value // is gracefully 
withdrawn. 1 If it would conflict with other assumptions, then one assumption is chosen arbitrarily 
and withdrawn. 

Similarly, (oneof list) takes a lisp list of values and generates a cell which takes on one of 
the values in list. If taking on one value leads to a contradiction, it is withdrawn as for assume and 
a new value is tried. For example, (oneof '(0 1 2)) generates a cell that tries to take on one 
of the values 0,1, or 2. It might appear that 

(== x (oneof '(0356 9))) 

is exactly the same as (and therefore simply shorthand for) 

(== x (assume 0)) 

(== x (assume 3)) 

(== x (assume 5)) 

(== x (assume 6)) 

(== x (assume 9)) 

but this is not so. The latter says that x tries to take on one of the values 0, 3, 5, 6, or 9, other 
things being equal. If, however, some external constraint on x requires x to be 4, then all these 
assumptions quietly bow out. On the other hand, oneof imposes the constraint that x must take 
on some one of these values. If some external constraint on x requires x to be 4 when tine oneof 
construct has been used as above, then a contradiction occurs. 


1. It is thus arbitrarily assumed that assumptions are less important than defaults or constants. One might want to 
have something like a default which was less important than an assumption. Indeed, the question of persistence for 
a cell and the question of which is chosen for retraction in case of conflict are orthogonal. 
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FlGL’RH 5-2. A Temperature Conversion Network, after Retracting an Assumption. 


5.2. Implementation Problems 

There are some difficulties with implementing these constructs. The primary problem is that 
they cannot operate using purely local information. This will be solved by recording extra informa¬ 
tion about the structure of the network so that assumption cells will have the information they need 
immediately to hand. 


5.2.1. Nogood Sets Can Ik* Used to Locally Record Contradictions 

Consider first the assume mechanism. Suppose, in a temperature conversion network, that 
centigrade is assumed to be zero: 
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(== centigrade (assume 0)) 

This causes the computation (on the basis of this assumption) of the value 32 for fahrenheit 
(sec Figure 5-1; the assumption is indicated by a hexagonal shape). Suppose then that 
fahrenheit is equated to the default value —40. This of course causes immediate detection of a 
contradiction. The contradiction mechanism, tracing the premises of the contradictory values, finds 
that the premises arc three constant cells, a defaul t cell, and an assume cell, the last is 
chosen as the culprit and retracted. At this instant, just after the retraction of the assumption and 
the forgetting of the consequences, the situation is as shown in Figure 5-2. Once values have been 
forgotten, then every the owner (if any) of every retracted cell is awakened, to request it to compute 
a value if it can. 

Here, then, is the problem. If the assumption cell is awakened in the “obvious” way, it will 
gladly supply a value for its cell. (It cannot tell at this point that this value is contradictory. All it 
can tell locally is that its cell has no value, and it has been asked to supply a value.) From this value 
new deductions may proceed. Indeed, before you know it the value 32 might be re-deduced for 
f ahrenhe i t! This would trigger a new contradiction, and the result is that the system might oscil¬ 
late, forever thrashing. Hvcn if deductions from fahrenheit made any headway (say through 
the first multiplication device), deductions from the assumption might continue to beat against 
them at intermediate points. 

One approach to solving this problem would be to assign priorities to propagation possibilities: 
values not depending on assumptions should be propagated in preference to values not depending 
on assumptions. Of course, this in effect implies carrying around information with each value 
describing its origin. This amounts to carrying around extra non-local information about distant 
parts of the network. Moreover, so far it has not been necessary to place any restrictions on the 
order in which propagation step are carried out by the system; indeed, we wish to preserve as much 
as possible the property that propagations may be performed in parallel. 

If we are committed to recording some kind of non-local information, we might as well do it 
right, in a straightforward way. We will introduce the mechanism of nogood sets [Stallman 1977]. A 
nogood set records a set of premises which have been found to be inconsistent. When a contradic¬ 
tion occurs at least one of whose premises is an assumption, then a list of the premises is made up. 
This list is recorded in each premise’s node. When an assumption cell considers trying to assert an 
assumed value for its node, it can first check all of the nogood sets associated with that node. If the 
assumed value would eventually cause the reoccurrence of a contradiction which has already been 
noted once and recorded in the form of a nogood set, then the assumption cell can avoid asserting 
the value. 

Nogood sets record value information about the network, information gained at some com¬ 
putational cost, concerning sets of incompatible values. They serve as a cache, so that blind alleys 
need not be re-cxplorcd over and over again. Instead, assumption cells can perhaps determine 
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locally and immediately that its value will eventually cause a contradiction in the current situation. 
Nogood sets therefore provide a semi-predicate for the safety of the assumed value: the absence of 
a relevant nogood set does not guarantee that trying a value will succeed, but the presence of one 
can immediately guarantee that it must fail. 

The formation of nogood sets of course constitutes a kind of algebra on the network. Rach 
set summarizes some computation tree in terms of a set of values for its leaves known to be incom¬ 
patible. Indeed, we might want to think of a nogood set as another kind of constraint: a redundant 
constraint that a certain set of nodes may not all simultaneously take on certain associated values, 
and that assumption cells know about specially. For efficiency (?), however, we will not actually 
implement them as constraint devices. (Another reason is that the language does not have sets as 
data objects.) 


5.2.2. Resolution Can Derive New Nogood Sets from Old Ones 

We turn now to the oneof construct. Suppose that the node to which a oneof cell is 
connected has no value, and the oneof cell is asked to supply a value. It can examine its set of 
possibilities, possibly filter out some of them by consulting the nogood sets recorded in the node, 
and then arbitrarily choose one of the remainder to assume. 

Further suppose, however, that the recorded nogood sets rule out all of the possible choices; 
that is, for each choice there is a nogood set which rules out that choice. What then can be done? 
Let us refer to the nogood set that rules out a choice as a “killer” of that choice. Now a nogood 
set is a mapping of nodes to particular values, and asserts that not all the nodes may take on the 
associated values, because that has been previously determined to be a contradictory suite. For 
a nogood set to be a killer for a choice for a node, it must be the case that every other node in 
the killer must currently bear its associated value. By an abuse of terminology let us call all these 
other nodes the premises of the killer (they arc the grounds for assuming that the choice cannot 
hold). Since the oneof construction indicates that it is a contradiction not to be able to choose 
any of the values, then all the premises of all the killers must be collectively responsible for this 
contradiction. It follows that these collective premises themselves constitute a nogood set, which 
can be duly recorded. The result is that from several nogood sets sharing a common node, each 
forbidding one value for that node, a new nogood set can be derived not containing that node. 

As an example, consider the network of figure 5-3. The node named confusion has 
attached to it three little sub-networks and a oneof choice. One network states that whatever 
confusion is, 

confusion -f- confusion = confusion X confusion 

must hold. This is a quadratic equation with roots 0 and 2; however, this subnetwork cannot 
compute a value for confusion by local propagation. The second subnetwork states that 
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confusion is the maximum of 1 and something else. The third says that confusion cannot be 
2. Neither of these can compute a value for confusion by local propagation, cither. 

The oneof cell (indicated by a hexagonal shape with a set inside it) will assume some value 
of its set. Suppose that it assumes 0 is the value. Then a contradiction will occur in the inaxe r 
device, for 0 cannot be the maximum of 1 and anything else (Figure 5-4). The set of premises 
causing this contradiction is the assumption 0 and the constant 1. Thus a nogood set is created: 

{(assumption-cell, 0), (constant-1,1)} 

(Here we notate a nogood set as a mathematical set of ordered pairs (cell, value).) The assumed 
value 0 is retracted, and all consequent deductions forgotten. T his leaves us back where we started, 
except for the newly created nogood set. 
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The oneof cell, true to its nature, would still like to assume some value. Consulting the 
available nogood sets, it discovers that 0 is currently forbidden. Suppose that it chooses 1. Then 
a contradiction will occur somewhere in the little quadratic equation, for 1 is not a root of the 
equation (Figure 5-5). The set of premises causing this contradiction is the assumption 1 (the 
quadratic equation contains no constants!), dims another nogood set is created: 

{(assumption-cell, 1)} 

In other words, l simply can never work in the current network, even if constants or defaults are 
retracted. The assumed value 1 is retracted, and all consequent deductions forgotten. This leaves us 
once more back where we started, except for another nogood set. 

The oneof cell still tries to assume some value, flic existing nogood sets now rule out both 
0 and 1, and so 2 is chosen. T his causes a contradiction in the equality device (Figure 5-6). (It 
also happens to compute the value 2 for the variable loose, which hangs loose from the maxer 
device.) The set of premises causing this contradiction is the assumption 2, the constant 2, and the 
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default value 0. Thus another nogood set is created: 

{(assumption-cell, 2), (constant-2, 2), (default-0, 0)} 

The assumed value 2 is retracted, and all consequent deductions forgotten. This leaves us yet again 
back where we started, except for yet another nogood set. 

Once again the oneof cell tries to assume a value. Now it discovers that every possibility 
is ruled out. The constant l prevents the choice of 0; the choice of 1 is flatly forbidden; and the 
constant 2 and the default 0 rule out the choice of 2. Since one of the three choices must hold, 
this constitutes a contradiction. The three nogood sets are merged, eliminating the assumption-cell 
entries, to form a fourth nogood set: 

{(constant-1,1), (constant-2, 2), (default-0,0)} 

This constitutes a resolution step on the nogood sets. Now the contradiction mechanism of Chapter 
Four goes to work, and finding that there is exactly one default cell involved, automatically 
retracts that value. 

One last time the oneof cell contemplates its situation. There are three nogood sets to con¬ 
sider. The value 0 is still ruled out, because the constant cell I still has its value. The value 1 
is still ruled out. The value 2, however, is not now ruled out, because one cell of that nogood set 
(the default cell) now has no value. Hence the oneof cell is again free to choose 2 for its value. 
This eventually propagates throughout the network, and computes the value 1 for the default 
cell which was formerly 0 (Figure 5-7). 
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5.3. Implementation of Assumption Mechanisms 

To implement the assumption mechanisms we need a way to represent the “persistence” of an 
assumed value, and also a data structure for representing nogood sets. We will treat an assumption 
as a funny kind of constraint, one which (sometimes) computes a value without requiring any 
inputs. The constraint needs to know what value (for assume) or values (for oneof) to choose 
from. To this end a new component info is added to every constraint. Not every constraint will use 
it (indeed most will not); it is a catch-all component for sticking extra things into. This component 
will find yet other uses in later chapters. 

A nogood set will be represented as a header plus a sorted list of pairs, each pair being a cons 
of a repository (used to uniquely represent a node) and a value (an integer). Each repository will 
bear an identification (an hi component similar to that for cells and constraints), and the pairs of a 
nogood set are sorted by alphabetical ordering on this repository identification. (The only reason 
for the id component in each repository is for sorting purposes, and the only reason for sorting is so 
that certain linear algorithms can be used on nogood sets.) The header will be simply the symbol 
nogood. This is present purely so that a nogood set can be altered by sidc-eiTect; if every place 
that knows about the nogood set points only to the header, then alterations of the nogood set will 
be visible to all. Thus a nogood set might look like this: 

(N0G000 (<REP-12> . 5) (<REP-15> . -3) (<REP-23> . 6)) 

This is a nogood set with three pairs. 

Every repository mentioned in a nogood set needs to know about that nogood set. Hence 
another new component, nogoods , is added to each repository. This could be simply a list of all 
nogood sets mentioning that repository, but to speed up searching it will be divided into “buckets” 
according to \hc value associated with that repository in the nogood. Thus, for a given repository,all 
the nogoods associating value 0 with that repository will be in bucket 0; for the value 1, bucket 1; 
for the value —43, the bucket —43, etc. Thus, to check whether a certain value n is assumable 
for a repository, only nogood sets in bucket n need be checked. For fastest access to a bucket, the 
buckets could be kept in a hash array. We will not be that complicated here; instead, the nogoods 
component will simply be an a-list, associating buckets with values. However, the a-list pairs will 
be kept sorted by values, again for speed. In all, a repository’s nogoods component might look like 
this: 

((-3 (NOGOOD (<REP-12> . 5) (<REP-15> . -3) (<REP-23> . 6)) 

(NOGOOD (<REP-15> . -3) (<REP-43> . -20))) 

(0 (NOGOOD (<REP-11> . -4) (<REP-15> . 0))) 

(7 (NOGOOD (<REP-14> . 2) (<REP-15> . 7) (<REP-23> . -7) (<REP-43> . 27)) 

(NOGOOD (<REP-15> . 7) (<REP-24> . 0) (<REP-43> . 0)) 

(NOGOOD (<REP-6> . 3) (<REP-14> . -7) *(<REP-15> . 7) (<REP-43> . 27))) 

(9 (NOGOOD (<REP-15> . 9)))) 
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|(deftype constraint (con-id con-name con-ctype con-values con-info) 

(format stream :~]~S>" (con-name constraint) (con-id constraint))) 

(deftype repository ((rep-contents ()) (rep-boundp ()) (rep-cells ()) 

(rep-supplier ()) (rep-rule ()) (rep-mark ()) 

| rep-id (rep-nogoods '{))) 

(format stream ”<Repos i tory~:[~*~;: ~S~]~@[ for /] ]>" 

(rep-boundp repository) 

(rep-contents repository) 

(cell-ids repository))) 

(defmacro node-contents (cell) ‘(rep-contents (ce11-repository ,cell))) 

(defmacro node-boundp (cell) ‘(rep-boundp (cell-repos i tory ,cell))) 
(defmacro node-cells (cell) ‘(rep-cells (cell-repos itory ,cell))) 

(defmacro node-supplier (cell) ‘(rep-supplier (cell-repository ,cell))) 
(defmacro node-rule (cell) -(rep-rule (cel 1 - repository ,cell))) 

(defmacro node-mark (cell) ‘(rep-mark (cel 1 - repository ,cell))) 

|(defmacro node-nogoods (cell) ‘(rep-nogoods (cel 1-repository ,cell))) 

(defun gen-repository () 

(let ((r (make-repository)) 

(n (gen-name 'rep))) 

(setf (rep-id r) n) 

(set n r) 

r )) 

(defun node-lessp (x y) 

(require-cel 1 x) 

(require-cel 1 y) 

(alphalessp (rep-id (cell-repository x)) (rep-id (cel 1-repository y)))) 
Compare this with Table 3-1 (page 75) and 1'able 2-3 (page 49). 

Table 5-1. Data Structure Modifications for Assumptions. 


This nogoods component has four buckets, which arc sorted according to the values —3, 0, 7, 
and 9. These buckets have 2, 1, 3, and 1 nogood sets, respectively. This is evidently the nogoods 
component of repository number 15. The buckets are not sorted (they could be sorted by a lexi¬ 
cographic order, but this did not seem to be worthwhile for the present purposes). Rach entry of 
each bucket (i.e., each nogood set) is sorted by repository id. 

Table 5-1 shows the necessary changes to the constraint and repository data struc¬ 
tures. As usual, a macro node-nogoods is defined to access the nogoods given a repre¬ 
sentative cell of a node. The function gen-repos itory generates a repository and associates 
a unique lisp variable name with it, also in the usual manner. Everyplace that used to 
call make-repository (these places arc in gen-cell, disconnect, and dissolve) are 
changed to call gen - repos i tory. (The new definition of gen-cel 1 is not shown here, as that 
is the only change to that function.) The predicate node-lessp orders two nodes according to 
the alphabetical order of the id’s of their respective repositories. 
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(defprim assumption (pin)) 

(progn 'compile 

(defun assumption-rule (*me*) 

(let ((*rule* 'assumption-rule) 

(pin-cell (the pin *me*))) 

(or (node-boundp pin-cell) 

(let ((value (con-info *me*))) 

(do-named outer-loop , ... 

((x (edr (assoc value (node-nogoods pin-cell))) (edr x))) 

((null x) (setc pin value)) 

(do-named inner-loop 

((c (edar x) (edr c))) 

((null c) (return-from outer-loop)) 

(and (not (eq (caar c) (cel 1-repository pin-cell))) 

(or (not (rep-boundp (caar c))) 

(not (equal (rep-contents (caar c)) (edar c)))) 

(return-from inner-loop)))))))) 

(push 'assumption-rule (ctype-rules assumption)) 

(defprop assumption-rule () trigger-names) 

(defprop assumption-rule (pin) output-names) 

(defprop assumption-rule assumption tentative) 

'(assumption rule)) 

(defun assume (value) 

(let ((a (gen-constraint assumption ()))) 

(setf (con-name a) (con-id a)) 

(setf (con-info a) value) 

(awaken a) 

(the pin a))) 

Table 5-2. Implementation of the assume Construct..__ 


The implementation of the assume construct is shown in I able 5-2. A special kind of ptimi- 
tive constraint called an as sump t ion is first defined. It has a single pin called pin, and no lules 
of the usual kind. The function assumption-rule implements a special rule for assumptions, 
which unlike other rules has no triggers. The function’s argument is called *me*, and die first thing 
it does is to bind the variables *rule* and pin- cell; this is in accordance with convention so 
that the setc construct can be used within the rule (see Tabic 4-3 (page 124)). 

If the pin is not bound, then the assumption rule considers asserting an assumed value. I he 
relevant value is stored in the info component of the constraint (which is passed in as *me*). lhe 


assumption rule performs a set of two nested loops, l he outer loop fetches the bucket associated 
with the value from the node’s nogoods component, then iterates over the contents of the bucket 
(each element is a nogood set). If each nogood set passes a test (that it not currently forbid the 
value), then the pin is set to the value, using setc. 

The inner loop implements the nogood test. All the repositories in the nogood set arc checked. 
If any repository other than the one for the pin-cell is cither unbound or had a different value from 
the one associated with it in the nogood set, then that nogood set docs not forbid the value; hence 



144 


Chapter Five 


Assumptions 


(defprim oneof (pin)) 

(progn 'compile 

(push 'oneof-rule (ctype-rules oneof)) 

(defprop oneof-rule () trigger-names) 

(defprop oneof-rule (pin) output-names) 

(defprop oneof-rule oneof tentative) 

'(oneof rule)) 

(defun oneof (valuelist) 

(let ((a (gen-constraint oneof ()))) 

(setf (con-name a) (con-id a)) 

(self (con-info a) valuelist) 

(awaken a) 

(the pin a))) 

Tabu: 5-3. Implementation of the oneof Construct.. 


the inner loop may be exited, and the next nogood set tested. If the inner loop checks all the pairs 
of a nogood set without exiting, however, then the nogood set must forbid the value, and so the 
outer loop is exited. In other words, if p is the repository for the pin of the assumption, and b is the 
bucket of nogoods for the value, then the value is forbidden if 

3 n Eb (V(r, u) £ n (r 7 ^ p A rcp-boundp(r) A rcp-contents(r) = v)) 

The function assume generates an assumption constraint. It makes the name of the con¬ 
straint be the same as its id, installs the assumed value in the info field, and then—very impor¬ 
tant!—awakens the constraint. (Since the rule has no triggers, it is always triggcrable. If the 
assumption is not awakened now, it probably never will be, so it better be done now.) This will 
cause the assumed value to be asserted in the pin. Finally, the pin is returned. 

The push construct adds the rule to the set of rules for contraint-type assumption. The 
first two defprop forms define the set of triggers (empty) and outputs (the pin). 'The third 
defprop form defines the rule to be tentative ; that is, a value computed using that rule is very 
“weak”, and subject to automatic retraction. 2 Also, nogood sets should always be recorded for 
tentative values. 'Thisproperty will be used in process-contradiction. 

The implementation of oneof (Table 5-3) is similar to that for assume. There is a kind of 
constraint called a oneof, and the info component of the constraint holds the list of possibilities. 
There is a function oneo f which is analogous to the function assume— indeed, they are almost 
identical. 


2. Compare this with Brown's “weak rules”. [Brown 1980] 
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(defun oneof-rule (*me*) 

(let ((*rule* 'oneof-rule) 

(pin-cell (the pin *me*))) 

(let ((values (con-info *me*))) 

(cond ((node-boundp pin-cell) 

(or (member (node-contents pin-cell) values) 

(contradiction pin))) 

(t (do-named loop-over-possibilities 
((v values (edr v)) 

(killers '())) 

((null v) 

(ctrace "All of the values ~S for ~S are no good." 
values 

(cel 1-goodname pin-cell)) 

(let ((losers ' ())) 

(dolist (killer killers) 

(dolist (x (edr killer)) 

(or (eq (car x) (cel 1-repository pin-cell)) 
(let ((cell (if (rep-boundp (car x)) 

(rep-supplier (car x)) 
(car (rep-cells 

(car x)))))) ;?? 

(or (memq cell losers) 

(push cell losers)))))) 
(process-contradiction losers)) 

(oneof-rule *me*)) 

(do-named outer-loop 

((x (edr (assoc (car v) (node-nogoods pin-cell))) 
(edr x))) 

((null x) 

(setc pin (car v)) 

(return-from loop-over-possibil i ties)) 

(do-named inner-loop 

((c (edar x) (edr c))) 

((null c) 

(push (car x) killers) 

(return-from outer-loop)) 

(and (not (eq (caar c) (cel 1-repository pin-cell))) 

(or (not (rep-boundp (caar c))) 

(not (equal (rep-contents (caar c)) (edar c)))) 

(return-from inner-loop)))))))))) 

Table5-4. The Rule for oneof. 


The difference between assume and oneof is expressed in the function oneof-rule 
(Table 5-4). If the pin has a value, then it must be in the permitted set of values, or else a contradic¬ 
tion is signalled. If the pin has no value, then a more complicated search is performed. There is a 
third loop nested outside the other two, which loops over the possible choices. For each choice the 
same test used by assumption-rule is performed, trying to find a nogood set that will forbid 
the value. If none is found, then die value is installed in the pin, and the loop over the possibilities 
is exited, as a valid choice has been found. If, however, for a given possibility a nogood set is found 
which docs forbid that choice, then there is no hope for that value. The nogood set is a killer for die 
value, and is remembered by pushing it onto the list killers. 
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(defun process-contradiction (ceils) 

(let ((premises (premises* cells))) 

(do ((x premises (cdr x))) 

((null x) 

(let ((losers (do ((p premises (cdr p)) 

(z '() (if (eq (node-rule (car p)) 'default) 

(cons (car p) z) 

*))) 

((null p) (or z premises))))) 

(cond ((null losers) (lose "Hard-core contradiction!")) 

((null (cdr losers)) 

(retract (car losers))) 

(t (retract (choose-culprit losers)))))) 

(cond ((get (node-rule (car x)) 'tentative) 

(ctrace "Deeming ~S in ~S (computed by rule ~S) to be the culprit." 
(node-contents (car x)) 

(ce 11 - id (car x)) 

(node-ru1e (car x))) 

(forin-nogood-set premises) 

(retract (car x)) 

(return)))))) 

Compare this with Table 4-4 (page 125). 

Table 5-5. Looking for Tentative Values for Use as Culprits. 


If any valid choice is found, then it is installed as described above. If no valid choice is found, 
then a killer nogood set has been found for each choice. In this case oneof - rul e announces (via 
ctrace) that all the possibilities have been ruled out. It then takes the union of all the repositories 
in all the killers, other than the repository for the pin itself, accumulating them in the list losers 
(actually, for each repository a representative cell is found; if the repository has a value, then its 
supplier is used, and otherwise one is chosen arbitrarily 3 ). 

The list losers is eventually a set of cells in contradiction produced by resolution of the set 
of killers. These cells are given to process-contradiction. When contradiction processing 
has ended, oneof-rul e rc-invokes itself to try choosing again. 

When a contradiction occurs, the central handler process-contradiction is called. This 
function is changed ('Fable 5-5) to have three priority levels for culprits: just as def aul t values 
are preferred to constant values, so values computed by a tentative rule are preferred to either. 
Thus there is an extra search loop, which first checks all the premises for a tentative value. If any is 
found, it is immediately deemed to be the culprit, and a nogood set is constructed and recorded for 
this contradiction. The culprit is then retracted in the usual manner. 


3. TTic latter case should of course never occur, but coding it this way allows for general non-monotonic rules later 
which are triggered by the lack of a value in the same way that assumption-rule and onoof-rule are. In this 
case the “unbound value” might usefully appear in a nogood set. 



§5.3 


Implementation of Assumption Mechanisms 147 


(defun form-nogood-set (cells) 

(setq cells (sort (append cells '()) #'node-lessp)) 

(ctrace "The set~:{~<~'X; | ~8X~: 15; ~S=~S~>~:t,~/]~<~%;|~8X~:15; is no good.~>" 
(forlist (c cells) (list (cel 1-goodname c) (node-contents c)))) 

(let ((nogood (cons 'nogood 

(foriist (c cel 1s) 

(cons (cel 1-repository c) (node-contents c)))))) 

(dolist (cell cells) 

(let ((slot (assoc (node-contents cell) (node-nogoods cell)))) 

(cond (slot (or (member nogood (cdr slot)) (push nogood (cdr slot)))) 
((or (null (node-nogoods cell)) 

(< (node-contents cell) (caar (node-nogoods cell)))) 

(push (list (node-contents cell) nogood) (node-nogoods cell))) 

(t (do ((ng (node-nogoods cell) (cdr ng))) 

((or (null (cdr ng)) 

(< (node-contents cell) (caar (cdr ng)))) 

(setf (cdr ng) 

(cons (list (node-contents cell) nogood) 

(cdr ng))))))))))) 

Tablh 5-6. Constructing and Recording a Nogood Set. 


It is essential that a nogood set be recorded if a tentative rule is involved, because the rule will 
depend on the existence of that set not to keep making the same poor choice over and over. It is 
not necessary to record a nogood set if only constant and default values are involved. It might be 
useful, of course; the ordinary propagation mechanism could check nogood sets in order to detect 
contradictions earlier. This might be particularly useful if the user is trying one default value after 
another while twiddling some parameter: the == mechanism (in merge-values, perhaps) could 
check nogood sets before attaching a new value in order to detect a bad value quickly. There is a 
trade-off between the space and time needed to record a nogood set and the time needed to check 
them, and the overhead of repeatedly rediscovering the same contradictory situation if premises are 
being varied rapidly. However, it is unclear whether this is worth it; it is a good subject for future 
statistical research. 

The function form-nogood-set ('fable 5-6) takes a list of nodes (i.e., representative cells), 
and constructs and records a nogood set for their current values. First the nodes are sorted accord¬ 
ing to tlie node-1 essp predicate, to ensure that the nogood set will be properly sorted. (The call 
to append is intended to copy the list of nodes, because the sort primitive is destructive.) After 
a trace message is printed, the nogood a-list is constructed. Then for every node, the new nogood 
set is installed in Uiat node. This involves using assoc to get die relevant bucket. If the necessary 
bucket exists, the nogood set is added to die bucket. Otherwise a new bucket must be created and 
inserted in the correct place to keep the list of buckets properly sorted. This involves some tedious 
special cases. 

T he trouble with adding an interesting new feature is always that it interacts with everything 
else. Nogood sets are no exception. What should happen to the nogood sets when two nodes are 
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(defun == (cell 1 cell2) 

(require-cel 1 celll) 

(require-cel 1 cell2) 

(or (eq (cel 1-repository celll) (cel 1-repository cell2)) 

(let ((newval (merge-values celll cel!2))) 

(let ((rl (cel 1-repository celll)) 

(r2 (cel 1-repository cell2)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp cel!2))) 

(let ((r (cond ((eq (rep-rule rl) 'constant) rl) 

((eq (rep-rule r2) 'constant) r2) 

((or (not cb2) (and cbl (ancestor celll cell2))) rl) 
(t r2))) 

(rcells (append (rep-cells rl) (rep-cells r2)))) 

(setf (rep-contents r) newval) 

(let ((newcomers (if cbl (if cb2 '() (rep-cells r2)) 

(if cb2 (rep-cells rl) '()))) 

(xr (if (eq r rl) r2 rl))) 

(setf (rep-cells r) rcells) 

(dolist (cell (rep-cells xr)) (setf (cel 1-repository cell) r)) 
(let ((fcells (alter-nogoods-rep xr r))) 

(setf (rep-nogoods r) 

(merge-nogood-sets (rep-nogoods r) (rep-nogoods xr))) 
(awaken-all fcells)) 

(awaken-all newcomers) 

'done)))))) 

Compare this with Table 4-2 (page 123). 

Table 5-7. Merging Nogood Sets When Equating Cells. 


equated? According to our principle of order-independence, everything ought be be just as if the 
equating had happened first, followed by creation of the nogood sets. This is not simple. 

The necessary changes to == are shown in Table 5-7. A variable xr has been introduced 
to stand for the repository which will be thrown away; thus r and xr are rl and r2 or vice 
versa. Now if a value was no good for xr before, then it will certainly be no good for r, because 
they are to be the same. Hence all the nogoods for xr must be carried over to r. The function 
al ter-nogoods-rep causes all the nogoods in xr to be modified to apply to r. Then the two 
collections of nogoods must be merged; in the process any duplicates are eliminated for searching 
efficiency later. (After all, there may have been two nogood sets that were identical except that one 
mentioned r and one mentioned xr.) 

'fhe function al ter-nogoods-rep returns a list of cells whose owners should be awakened 
after everything else has been done. These cells arc awakened by == after the nogood collections 
have been merged. 

'The function al ter-nogoods-rep (Tabic 5-8) must handle lots of special cases. It iterates 
over the nogoods component of x r. Tor each bucket it iterates over the nogood sets in that bucket. 
For each nogood set it uses assq to find the pair mentioning xr (which must be present—if it is 
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(defun alter-nogoods-rep (xr r) 

(let ((feel 1s '())) 

(dolist (bucket (rep-nogoods xr)) 

(dolist (nogood (edr bucket)) 

(let ((z (assq r (edr nogood))) 

(xz (assq xr (edr nogood)))) 

(cond ((null xz) 

(lose "Funny nogood set ~S for bucket ~S of repository ~S." 
xr (car bucket) nogood)) 

((null z) 

(setf (edr nogood) 

(add-nogood-pair r (edr xz) (delassq xr (edr nogood))))) 
((equal (edr z) (edr xz)) 

(setf (edr nogood) (delassq xr (edr nogood)))) 

(t (dolist (pair (edr nogood)) 

(setq fcells (append (rep-cells (car pair)) feel Is)) 

(let ((buck (assoc (edr pair) (rep-nogoods (car pair))))) 

(or buck (lose "Nonexistent bucket: ~S.” pair)) 

(setf (edr buck) (delq nogood (edr buck))) 

(or (edr buck) 

(setf (rep-nogoods (car pair)) 

(delrassq '() (rep-nogoods (car pair)))))))))))) 


fcells)) 


(defun add-nogood-pair (rep val nogoodlist) 

(require-repository rep) 

(cond ((null nogoodlist) (list (cons rep val))) 

((node-lessp (car (rep-cells rep)) (car (rep-cells (caar nogoodlist)))) 
(cons (cons rep val) nogoodlist)) 

(t (cons (car nogoodlist) (add-nogood-pair rep val (edr nogoodlist)))))) 


Table 5-8. Altering Nogood Sets for a New Repository. 


not, an internal error has been detcetcd), and possibly a pair mentioning r. If a pair mentioning r 
is not found, then the pair mentioning xr is deleted from the nogood set, and a pair mentioning r 
with the same value is added (it must be added in the correct place to keep the nogood set sorted). 
Now if there is a pair mentioning r, then there arc two cases, depending on whether or not the 
mentions of r and xr associate the same value with each. If the values are the same, then the 
mention of xr should be deleted; the nogood relationship still holds, because once r and xr are 
merged, then r holding die value is the same as xr holding the value. If the values arc different, 
then the nogood relationship can never hold (one of the two cases cannot hold), and so die entire 
nogood set might as well be eliminated; die nogood set must be deleted from every bucket which 
contains it. Every such bucket can of course be found from the repository-value pairs of the nogood 
set. As an extra but unnecessary space-saving twist, if deleting a nogood set from a bucket makes 
the bucket empty, then the bucket is removed from the list of buckets for that bucket’s repository. 

If a nogood set is eliminated, dien all owners of cells in all the nodes whose repositories are 
mentioned in the nogood set must be awakened. This is because the nogood set might be the reason 
that some assume cell is not currently asserting its assumed value. Such assume cells must be 
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(defun merge-nogood-sets (si s2) 

(cond ((null si) s2) 

((null s2) si) 

((< (caar si) (caar s2)) 

(cons (car si) (merge-nogood-sets (cdr si) s2))) 

((> (caar si) (caar s2)) 

(cons (car s2) (merge -nogood-sets si (cdr s2)))) 

(t (cons (cons (caar si) (merge-nogood-buckets (cdar si) (cdar s2))) 
(merge-nogood-sets (cdr si) (cdr s2)))))) 

(defun merge-nogood-buckets (bl b2) 

(cond ((null bl) b2) 

((member (car bl) b2) (merge-nogood-buckets (cdr bl) b2)) 

(t (cons (car bl) (merge-nogood-buckets (cdr bl) b 2))))) 

Tablh 5-9. Merging Two Collodions of Nogood Sets. 


awakened when the nogood set disappears, of them, because the network might be in a bad state 
until the caller has done some other clean-up first (this is the case in = = ). 

'flic function add-nogood-pa i r simply inserts a new pair into a nogood list in the correct 
position for keeping it sorted. 

The function merge-nogood-sets takes two lists of buckets of nogood sets, and merges 
them into a single collection, flic merging of the top-level list takes linear times, because the 
buckets are in sorted order. I lowcvcr, the entries in a bucket are not sorted, and so merging two 
buckets with the same value can take quadratic time. On the other hand, each bucket entry (a 
nogood set) is kept sorted, and so is in a canonical form which can be compared by the I ISP equal 
function (which is used by such primitives as member and assoc)—equal treats two objects of 
user-defined type (by def type) as being equal iff they arc eq. 

When a value for a node is forgotten, then any nogood sets mentioning that value for that 
node might have formerly been suppressing an assumption and might now not so suppress an 
assumption. In the forget function (Table 5-10), the old value must be remembered internally 
before it is destroyed, and then used to fetch the relevant bucket of nogood sets. Any cells of 
nogoods in that bucket are added to f cel 1 s (the list of cells to be returned for later awakening), 
provided that they arc not connected to the cell being forgotten and that they currently have no 
value. (A finer filter would first test the nogood set to sec whether it actually could be suppressing a 
value: if too many nodes of the nogood set were unbound, or had values not matching the nogood’s 
associated values, then the nogood would not be suppressing a value. On the other hand, it cannot 
hurt to awaken devices unnecessarily, except for the wasted effort involved. (On the third hand, to 
fail to awaken a device may be a disaster! [[JSussman 1975]) Ihe effort to filter the cells queued 
into feel 1 s here should be weighed against the effort of unnecessary re-awakening here. This is 
purely an efficiency issue that will depend on detoils of a particular implementation.) 
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(defun forget (cell ^optional (source () sourcep) (via () viap)) 

(require-cel 1 cell) 

(and sourcep (require -cel 1 source)) 

(and viap (require-cel 1 via)) 

(ctrace "Removing ~S from ~S~:[~3*~; because ~:[of ~;~S==~]~S~]." 
(node-contents cell) 

(cel 1-goodname cell) 
sourcep 

(and viap (not (eq via source))) 

(and viap (not (eq via source)) (cel 1-goodname via)) 

(and sourcep (cel 1-goodname source))) 

J (let ((oldvalue (node-contents cell))) 

(setf (node-boundp cell) ()) 

(setf (node-contents cell) ()) 

(setf (node-supplier cell) ()) 

(setf (node-rule cell) ()) 

(let ((fcells (append (rep-cells (cel 1-repos i tory cell)) '()))) 

(dolist (c (rep-cells (ce11-repository cell))) 

(and (cell-owner c) 

(dolist (value (con-values (cell-owner c))) 

(require-cel 1 value) 

(and (node-boundp value) 

(eq value (node-supplier value)) 

(meinq (cell-name c) 

(get (node-rule value) 'trigger-names)) 

(setq fcells (nconc (forget value cell c) fcells)))))) 
(dolist (nogood (cdr (assoc oldvalue (node-nogoods cell)))) 

(dolist (pair (cdr nogood)) 

(and (not (eq (car pair) (cel 1-repository cell))) 

(not (rep-boundp (car pair))) 

(setq fcells (append (rep-cells (car pair)) fcells))))) 

fcells))) 

Compare this with Table 4-5 (page 127). 

Table 5-10. Forgotten Values May Re-enable Suppressed Assumptions. 


If dealing with nogood sets is difficult when equating two nodes, it is nearly impossible when 
dissolving them. Dissolving nodes (or disconnecting single cells) disrupts network connections 
which had previously existed. Nogood sets implicitly contain information which is dependent on 
network structure, in a form which abstracts out the structure used to derive them—their very 
utility lies in this abstraction. When a node is dissolved, it may be very difficult to determine which 
nogood sets are still valid. The code here takes the easy way out—when a node is dissolved, all 
nodes reachable from the given node arc visited, and their nogood collections destroyed. This is 
guaranteed to be safe; nogood sets merely redundantly encache information about the network. 
This information can be re-derived (at some cost, of course) for the new topology. 

It would be possible to record in each node every nogood set that depended on die connec¬ 
tions in that node; a modified premises function could gather together the nodes gone through, 
and form-nogood- set could use that list make the necessary records. However, this involves 
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(defun dissolve (cell) 

(require-cel 1 cell) 

| (let ((fcells (fast-expunge-nogoods cell))) 
j (let ((r (gen-repository))) 

(awaken-all queue)))) 

| (awaken-all fcells)) 

' done) 

(defun disconnect (cell) 

(require-cel 1 cell) 

| (let ((fcells (fast-expunge-nogoods cell))) 

(let ((oldr (cel 1-repository cell)) 

| (newr (gen-repository))) 

(t (awaken-all (forget cell))))) 

| (awaken-all fcells)) 

' done) 

Compare with Table 4-8 (page 130) and Table 4-9 (page 131). 

Tabu: 5-11. Disconnections Wreak Havoc with Nogood Sets. 


some space and time overhead. If it is assumed that network structure changes slowly compared to 
changes of value, all that complexity may not be worthwhile. 

The changes to the dissolve and disconnect functions are shown in Table 5-11. Bach 
calls fast-expunge-nogoods before doing anything else, and each uses gen-repository 
instead of make-repos itory. After all the other work is done, then awaken-al 1 is applied 
to the list of cells returned by fast-expunge-nogoods. Otherwise the code is the same as in 
Table 4-8 (page 130) and Table 4-9 (page 131), and so the bulk of the code is elided in Table 5-11. 

fable 5-12 contains the code for fast-expunge-nogoods. It is a graph-marking algorithm 
that simply every node reachable from the given one, and destroys the nogood information 
in each node visited. The value of fast-expunge-nogoods-mark (which is returned by 
fast-expunge-nogoods) is a list of all the cells of all nodes visited which had any nogoods 
information. ( This could be refined to return only cells with owners, or only cells owned by 
assumptions.) It marks nodes as they arc visited, and as usual a post-pass resets the mark bits. 

As with al te r-nogoods- rep ( fable 5-8), the cells are returned because the nogood infor¬ 
mation being destroyed might have formerly prevented some assume cell from asserting its value. 
Once the nogood information has been eliminated (and any changes to the network have been 
made by the caller of fast-expunge-nogoods), then such assume cells must be awakened, 
so that they may have another chance to assert their values. 

There are a few trivial changes to various routines from die last chapter. The search for 
premises in the functions premises and f ast-premi ses must treat assumptions as premises. 
Because premises and f ast-premi ses perform the same work but the latter is faster in the 
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(defun fast-expunge-nogoods (cell) 

( require-cel 1 cell) 

(progl (fast-expunge-nogoods-mark cell) (fast-expunge-nogoods-umnark cell))) 

(defun fast-expunge-nogoods-mark (cell) 

(require-cel 1 cell) 

(cond ((not (markp cell)) 

(mark-node cell) 

(let ((fcells (and (not (null (node-nogoods cell))) 

(append (node-cells cell) '())))) 

(setf (node-nogoods cell) '()) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(dolist (v (con-values (cell-owner c))) 

(setq fcells 

(nconc (fast-expunge-nogoods-mark v) fcells))))) 

fcells)) 

(t '()))) 

(defun fast-expunge-nogoods-umnark (cell) 

( require-cel 1 cel 1) 

(cond ((markp cell) 

(unmark-node cell) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(dolist (v (con-values (cell-owner c))) 

(fast-expunge-nogoods-unmark v))))))) 

Table 5-12. Rapid Destruction of Potentially Invalid Nogood Information. 


(defun fast-premises-mark (cell) 

( require-cel 1 cel 1) 

(and (node-boundp cell) 

(let ((s (node-supplier cell))) 

(cond ((markp s) '()) 

(t (mark-node s) 

| (if (or (null (cell-owner s)) (get (node-rule s) 'tentative)) 

(list s) 

(fast-premises-mark* 

(forlist (name (get (node-rule s) 'trigger-names)) 
(*the name (cell-owner s)))))))))) 

Compare this with Table 4-7 (page 129). 

Table 5-13. Assumptions Are Considered to be Premises. 


worst case, from now on wc will show the code only for fast-premises, the changes for which 
(occurring in fast-premises-mark) are shown in Table 5-13. 

It would be nice if what knew how to print an assume or oneof cell in the same way it 
is typed. To this end a new convention is introduced whereby the occurrence of “!” in a treeform 
designates not a pin but instead the info component of a constraint. Thus the new treeform 
definitions in Table 5-14 specify how to print assume and oneof cells as desired. 
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(defprop adder ((c (+ a b)) (b (- c a)) (a (- c b))) treeforms) 

(defprop multiplier ((c {* a b)) (b (// c a)) (a (// c b))) treeforms) 
(defprop maxer ((c (max a b)) (b (arcmax c a)) (a (arcmax c b))) treeforms) 
(defprop minner ((c (min a b)) (b (arcmin c a)) (a (arcmin c b))) treeforms) 
(defprop equality ((p (= a b)) (b (arc= p a)) (a (arc= p b))) treeforms) 
(defprop gate ((p (0-if-unequal a b)) (b (-> p a)) (a (-> p b))) treeforms) 
(defprop assumption ((pin (assumption !))) treeforms) 

(defprop oneof ((pin (oneof !))) treeforms) 

Compare this with Table 3-15 (page 96). 

Tabi.i: 5-14. New treeforms Definitions. 


(defun tree-form-chase (cell shallow top) 

(require-cel 1 cell) 

(let ((s (node-supplier cell))) 

(cond ((and shallow (node-boundp cell)) (node-contents cell)) 

((and (not top) (not (singlenummarkp s))) 

((cel 1-owner s) 

(cond ((and (eq s cell) (not top)) (cell-goodname s)) 

(t (let ((treeform 

(cadr (assq (cell-name s) 

(get (ctype-name 

(con-ctype (cell-owner s))) 
'treeforms))))) 

(cons (car treeform) 

(forlist (n (edr treeform)) 

(cond ((eq n '!) (con-info (cell-owner s))) 

((and (node-boundp s) 

(not (memq n (get (node-rule s) 

'trigger-names)))) 

'?) 

(t (tree-form-chase (*the n (cell-owner s)) 

shallow 

()))))))))) 

((globalp s) (cell-name s)) 

(t (node-contents s))))) 

Compare this with Table 3-17 (page 100). 

Table 5-16. Constructing a Treeform with a !. 


To make this work a few odd patches are needed. (Large systems seldom spring forth 
full-grown as from the forehead of Athena; they evolve by small changes.) The change to 
tree-form-trace in Table 5-15 has nothing to do with the “!” convention, but rather ar¬ 
ranges for assumption cells to be “cuts” in the same way constant cells arc. One change to 
tree-form-deep-trace causes “!” not to be treated as a pin name; the other, and also the 
change to tree-form-deep , allows a treeform not to exist for some constraints, in which case 
that constraint is passed by and another tried. This will be useful later for avoiding the use of 
certain uninteresting constraint-types in explanations. 
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(defun tree-form-trace (cell shallow) 

(require-cell cell) 

(cond ((node-boundp cell) 

(let ((s (node-supplier cell))) 

(cond ((cell-owner s) 

(and (get (node-rule s) 'tentative) (nummark cell)) ;crock 
(or shallow 

(tree-form-trace-set (cell-owner s) 

(get (node-rule s) 'trigger-names) 
shallow))) 

(t (nummark cell))))) ;crock 

(t (let ((cells (node-cells cell))) 

(setf (node-supplier cell) 

(or (if shallow 

(or (tree-form-shallow cell cells) 

(tree-form-deep cell cells shallow)) 

(or (tree-form-deep cell cells shallow) 

(tree-form-shallow cell cells))) 

(if (cell-owner cell) 

(tree-form-deep-trace cell shallow) 
cell))))))) 

(defun tree-form-deep (cell cells shallow) 

(do ((z cells (cdr z))) 

((null z) ()) 

(and (not (eq (car z) cell)) 

(cell-owner (car z)) 

(let ((q (tree-form-deep-trace (car z) shallow))) 

(and q (return q)))))) 


I 


(defun tree-form-deep-trace (cell shallow) 

(let ((treeform 

(cadr (assq (cell-name cell) 

(get (ctype-name (con-ctype (cell-owner cell))) 
'treeforms ))))) 


(cond (treeform 

(tree-form-trace-set 


(cel 1-owner cel 1) 

(remq '1 (cdr treeform)) 
shallow) 


cell)))) 


Compare this with Table 3-16 (page 98). 


Table 5-15. Tracing Missing Treeforms and Treeforms with ! . 


Finally, tree -form- chase must fill in the info component when it sees a “!” in the 
treeform; this is shown in Table 5-16 (part of the code has been omitted; it is the same as in Table 
3-17 (page 100)). 

The code in Table 5-17 has nothing whatsoever to do with assumptions; it just patches a 
bug described in §4.2, where a solution had been promised. The patch is that process-setc, 
before signalling a contradiction, remembers the values which triggered the rule which invoked 
process-setc. The setc is retried only if all the triggers still have those values. 
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(defun process-setc (*me* name cell value rule) 

rule) 

(let ((values (forlist (tr triggers) (node-contents tr)))) 
(P rocess-contradiction (cons cell triggers)) 

(do ((x triggers (cdr x)) 

(v vaIues (cdr v))) 

((null x) (process-setc *me* name cell value rule)) 
(or (and (node-boundp (car x)) 

(equal (node-contents (car x)) (car v))) 
(return))))))))) 

This code patches a problem in the code in Table 4-3 (page 124). 

Tahif.5-17. A More Reliable Version of process-setc. 


The solution was delayed until this chapter, rather than being given in Chapter Four, because 
now we arc in a position to poke a hole in this solution. With the advent of such strange rules as 
as sumption-rule, which in effect trigger on the absence of a value rather than the presence of 
one, it is not clear that this patch is adequate. It will work for presently defined rules, but may not 
be general enough for other types of rules. 
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5.4. Examples of the Use of Assumptions 

To illustrate the uses of assumptions, two examples arc given here. One illustrates the special 
cases needed to awaken assume cells; the other uses oneof cells and some additional constraints 
to solve the four queens problem. 


5.4.1. Simple Assumptions Are Persistent 

To exhibit the behavior of simple assumptions, we will ring the changes on a simple maxer 
device, in the following example, all c trace output concerning the awakening of devices has 
been suppressed without trace (pun intended). All other trace output is shown here. 

(create u maxer) 

<U:MAXER-61> 

If the a is assumed to be 1 and the b is assumed to be 2, then from these assumed values the 
maximum 2 can be computed. 

(== (the a u) (assume 1)) 

;|<ASSUMPTI0N-68:ASSUMPTI0N-68> computed 1 for its part PIN. 

DONE 

(== (the b u) (assume 2)) 

;|<ASSUMPTI0N-71:ASSUMPTI0N-71> computed 2 for its part PIN. 

; 1<U:MAXER-61> computed 2 for its part C from pins A, B. 

DONE 

Interrogation indicates that indeed the c was computed in this way. 

(what (the c u)) 

;The value 2 in CELL-67 was computed in this way: 

; (THE C U) <- (MAX (ASSUMPTION 1) (ASSUMPTION 2)) 

OKAY? 

Now we shall insist (by a default statement) that the c really ought to be 3. 

(== (the c u) (default 3)) 

; (Contradiction when merging <CELL-67 (C of U): 2> and <CELL-75 (DEFAULT): 3>. 
;|Deeming 2 in CELL-73 (computed by rule ASSUMPTION-RULE) to be the culprit. 

; |The set (THE PIN ASSUMPTION-68) = 1, (THE PIN ASSUMPTION-71)=2, 

;| CELL-75=3 is no good. 

;jRetracting the premise <CELL-73 (PIN of ASSUMPTION-71): 2>. 

;(Removing 2 from (THE PIN ASSUMPTION-71). 

;|Removing 2 from (THE C U) because (THE B U)==(THE PIN ASSUMPTION-71). 
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; | <U:MAXER-61> computed 3 for its part B from pins A, C. 

DONE 

This of course caused a contradiction between the default value 3 and die computed value 2. 
Because die latter was computed from assumptions, one of the assumptions was arbitrarily chosen 
to be the culprit and retracted. 4 

(what (the c u)) 

;The value 3 in CELL-67 was computed in this way: 

; (THE C U) «- 3 
OKAY? 


Indeed the value 2 has disappeared, and been replaced by the specified def aul t value. 

(what (the a u)) 

; T h e value 1 in CELL-63 was computed in this way: 

; (THE A U) <- (ASSUMPTION 1) 

OKAY? 

The assumption for a is still in force. 

(what (the b u)) 

;The value 3 in CELL-65 was computed in this way: 

; (THE B U) «- (ARCMAX 3 (ASSUMPTION 1)) 

OKAY? 

On the other hand, the assumption for b has been retracted, and b was computed from the default 
value 3 and the assumption 1. 

Now, to make things more complicated, let us insist that a be 5. 

(== (the a u) (default 5)) 

; (Contradiction when merging <CELL-63 (A of U): 1> and <CELL-77 (DEFAULT): 5>. 
;|Deeming 1 in CELL-70 (computed by rule ASSUMPTION-RULE) to be the culprit. 

; |The set (THE PIN ASSUMPTION-68) = l, CELL-77 = 5 is no good. 

;|Retracting the premise <CELL-70 (PIN of ASSUMPTION-68): 1>. 

; | Removing 1 from (THE PIN ASSUMPTION-68). 

The default value 5 conflicted with the assumed value 1, and the latter was therefore retracted. A 
nogood set was formed in the process. 

; (Removing 3 from (THE B U) because (THE A U) = = (THE PIN ASSUMPTION-68). 

; | <ASSUMPTI0N-71:ASSUMPTI0N-71> computed 2 for its part PIN. 

; |<U:MAXER-61> computed 3 for its part A from pins B, C. 


4. Note that if several assumptions arc involved, the system currently chooses one arbitrarily. It might be useful to 
have a “hook” to allow a user function to discriminate among assumptions. 
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The value 3 for b had been computed from the assumption 1, and so must be retracted also. Once 
this is done, the old assumption for b is free to rc-asscrt the value 2. From this assumption and 
the value 3 on c, the value 3 = aremaxj 2 can be computed for a. This of course contradicts the 
default value 5 just placed there. 

;(Contradiction when merging <CELL-63 (A of U): 3> and <CELL-77 (DEFAULT): 5>. 
;|Deeming 2 in CELL-73 (computed by rule ASSUMPTION-RULE) to be the culprit. 

;j The set (THE PIN ASSUMPTION-71) = 2, CELL-75 = 3, CELL-77 = 5 is no good. 
;|Retracting the premise <CELL-73 (PIN of ASSUMPTION-71): 2>. 

;|Removing 2 from (THE PIN ASSUMPTION-71). 

;|Removing 3 from (THE A U) because (THE B U)==(THE PIN ASSUMPTION-71). 

The contradiction rested on the assumption of 2 for b, and so it was deemed the culprit and 

retracted again, along with its consequences. 

There remains a more fundamental contradiction, however: the default value 5 for a is 
incompatible with the default value 3 for c. 

;|Contradiction in <U:MAXER-61> among these parts: A=5, C=3. 

;;; These are the premises that seem to be at fault: 

; CCELL-77 (DEFAULT): 5>, 

; CCELL-75 (DEFAULT): 3>. 

;;; Choose one of these to retract and RETURN it. 

We choose to retract the value 3 from c. 

(return cell-75) 

;|Retracting the premise CCELL-75 (DEFAULT): 3>. 

;(Removing 3 from CELL-75. 

;j CASSUMPTION-71:ASSUMPTI0N-71> computed 2 for its part PIN. 

;j<U:MAXER-61> computed 5 for its part C from pins A, B. 

DONE 

Once die value 3 has been retracted, the assumption for b is free to rc-assert the value 2. T his 
occurs because when the default value 3 is forgotten for c, the nogood set {( b, 2), (c, 3), (a, 5)} is 
examined in the function forget and all relevant owners awakened. From this assumed value 2 
and the default value 5, the value 5 is computed for c. 

(what (the a u)) 

;The value 5 in CELL-63 was computed in this way: 

; (THE A U) «- 5 
OKAY? 

(what (the b u)) 

;The value 2 in CELL-65 was computed in this way: 

; (THE B U) <- (ASSUMPTION 2) 

OKAY? 

(what (the c u)) 
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;The value 5 in CELL-67 was computed in this way: 

; (THE C U) (MAX 5 (ASSUMPTION 2)) 

OKAY? 

Now a = 5, b = 2, and c = 5. 

Suppose now that wc assert the default value 0 for c. This is similar to the situation earlier 
where 3 was asserted for c, with one difference: then, the assumed values a — 1 and 6=2 were 
individually compatible with c = 3, and only in combination contradictory; here, however, the 
assumptions arc individually incompatible with c — 0, and so we expect both assumptions to be 
suppressed. 

(== (the c u) (default 0)) 

; (Contradiction when merging <CELL-67 (C of U): 5> and <CELL-79 (DEFAULT): 0>. 
;|Deeming 2 in CELL-73 (computed by rule ASSUMPTION-RULE) to be the culprit. 

;|The set (THE PIN ASSUMPTION-71)=2, CELL-77=5, CELL-79=0 is no good. 

; |Retracting the premise <CELL-73 (PIN of ASSUMPTION-71): 2>. 

;j Removing 2 from (THE PIN ASSUMPTION-71). 

;jRemoving 5 from (THE C U) because (THE B U) = = (THE PIN ASSUMPTION-71). 

The computed value 5 in c conflicted with the new value 0, and was withdrawn because it de¬ 
pended on an assumption. 

; (Contradiction in <U:MAXER-61> among these parts: A=5, C = 0. 

;;; These are the premises that seem to be at fault: 

; CCELL-77 (DEFAULT): 5>, 

; <CELL-79 (DEFAULT): 0>. 

;;; Choose one of these to retract and RETURN it. 

Moreover, the value 5 in for a conflicts with the value 0 for c. We will retract the value 5 for a. 

(return cell-79) 

; (Retracting the premise <CELL-77 (DEFAULT): 5>. 

;(Removing 5 from CELL-77. 

At this (highly volatile!) point, the only value extant is 0 for c. However, the assumptions are about 
to be awakened. 

;|<ASSUMPTION~71:ASSUMPTION-71> computed 2 for its part PIN. 

; (Contradiction in <U:MAXER-61> among these parts: B = 2, C = 0. 

;|Deeming 2 in CELL-73 (computed by rule ASSUMPTION-RULE) to be the culprit. 

; | The set (THE PIN ASSUMPTI0N-71) = 2, CELL-79 = 0 is no good. 

; (Retracting the premise <CELL-73 (PIN of ASSUMPTION-71): 2>. 

;(Removing 2 from (THE PIN ASSUMPTION-71). 

T he assumption for b tries out the value 2 and is rebuffed. A nogood set is formed, and the 
assumption retracted. 
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; |<ASSUMPTI0N-68:ASSUMPTI0N-68> computed 1 for its part PIN. 

; (Contradiction in <U:MAXER-61> among these parts: A=l, C = 0. 

;|Deeming 1 in CELL-70 (computed by rule ASSUMPTION-RULE) to be the culprit. 
; | The set (THE PIN ASSUMPTION-68)=1, CELL-79 = 0 is no good. 

; |Retracting the premise <CELL-70 (PIN of ASSUMPTION-68): 1>. 

; jRemoving 1 from (THE PIN ASSUMPTION-68). 

DONE 

Precisely the same late befalls the other assumption of l for a. It is still the case that the only extant 
value is 0 for c. However, it is now known why the assumptions cannot hold, and this information 
has been recorded in nogood sets. 

(what (the a u)) 

; C E L L-6 3 has no value. I can express it in this way: 

; (THE A U) = (ASSUMPTION 1) 

OKAY? 

(what (the b u)) 

;CELL-65 has no value. I can express it in this way: 

; (THE B U) = (ASSUMPTION 2) 

OKAY? 

These explanations are a little strange. Probably what should be augmented to use nogood infor¬ 
mation to explain the absence of a value, but this thought is not pursued here. 

l et us finally disconnect c from the other cells of its node (and in particular the default 
cell supplying the value 0). 

(disconnect (the c u)) 

; (Disconnecting (THE C U) from CELL-75, CELL-79. 

;(Removing 0 from (THE C U). 

;|<ASSUMPTION-71:ASSUMPTION-71> computed 2 for its part PIN. 

; |<ASSUMPTI0N-68:ASSUMPTI0N-68> computed 1 for its part PIN. 

;|<U:MAXER-61> computed 2 for its part C from pins A, B. 

DONE 

Disconnecting c from the source of the value 0 causes all the old nogood information to be ex¬ 
punged. This awakens the assumptions, which find no nogood sets to suppress their values. From 
the assumptions a new value is computed for c. 

(what (the c u ) ) 

;The value 2 in CELL-67 was computed in this way: 

; (THE C U) <- (MAX (ASSUMPTION 1) (ASSUMPTION 2)) 

OKAY? 


This brings us full circle, to the beginning of the example. 
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(declare (special *contradictions* ^backtracks*)) 

(defun queens (n) 

(setq *contradictions* 0) 

(setq *backtracks* 0) 

(queensearch '() n 0) 

(format t "~ Q /„Total of ~D contradictions and ~D backtracks." 

^contradictions* *backtracks*) 

' done) 

(defun queensearch (previous n k) 

(cond ((= k n) 

(format 
t 

"~%Solution: (~{~D~t,~}) after ~D contradictions and ~D backtracks." 
(reverse previous) *contradictions* *backtracks*)) 

(t (dotimes (i n) 

(do ((x previous (cdr x)) 

(j 1 ( + j 1))) 

((null x) 

(queensearch (cons i previous) n (+ k 1))) 

(cond ((or (= i (car x)) ;column test 

(= (- i (car x)) j) ;diagonal test 

(= (- (car x) i) j)) ;other diagonal test 

(ctrace "Contradiction: (~{~D~t,~}) kills ~D." 

(reverse previous) i) 

(increment *contradictions*) 

(return))))) 

(increment ^backtracks*)))) 

Table 5-18. A LISP Solution to the N Queens Problem. 


5.4.2. Oneof Assumptions Can Express and Solve the Four Queens Problem 

The generalized N queens problem is that of placing N chess queens on an N by N 
chessboard so that no two queens attack each other; that is to say, no two queens are on the same 
row, column, or diagonal. The usual approach notes that every row must have exactly one queen on 
it, and then tries to place one queen on each row. Using this idea the problem may be formulated 
as: for 0 < i < N find 0 < < N such that 

Vi Vj ((0 < i < N A 0 < j < N A i 7^ j) => 

('<lj 7^ <li A qj — Qi 7 ^ j~i A Qj qi 7 ^ i j)) 

This is a standard problem used to illustrate backtracking control structures, because a solution 
to the problem can easily be expressed as a non-deterministic program; for each row, non- 
dctcrministically choose a column in that row; then check to sec whether there is a conflict on any 
column or diagonal. In a sequential simulation of a non-deterministic program, a conflict causes a 
failure back to the most recent choice point. 
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A LISP program for the usual solution to the N queens problem is shown in Table 5-18. 
Rather than using explicit backtracking and failure mechanisms, it merely takes advantage of the 
observation in [Sussman 1972] that chronological backtracking mechanisms arc equivalent to a 
scries of nested do loops. Rich recursive call to queensearch tries to choose a column for 
one row (row /c; rows and columns arc numbered starting with 0). It loops over all choices from 
0 to N — l using dotimes, and for each choice checks for a conflict with all previous choices 
(which arc in the list previous). If a conflict is found, a contradiction is noted via the trace 
mechanism and a counter *con t rad ict ions* incremented (for statistical, not algorithmic, pur¬ 
poses). If no conflict exists, the choice is added to the previous list and a recursive call made to 
choose for the next row. If all choices fail, cither immediately or because a recursive call returned, 
then queensearch returns (after incrementing another counter, *backtracks*) so that the 
previous row may try a new choice. (The program as it stands will find all solutions, not just one. 
To find just one, a non-local exit could be made after printing a solution.) 

As an example of running the queens program, here is the output (with tracing turned off) 
for the cases N — 4, N — 6, and (in part) N = 8: 

NIL 

(queens 4) 

Solution: (1,3,0,2) after 18 contradictions and 4 backtracks. 

Solution: (2,0,3,1) after 26 contradictions and 7 backtracks. 

Total of 44 contradictions and 15 backtracks. 

DONE 

(queens 6) 

Solution: (1,3,5,0,2,4) after 140 contradictions and 25 backtracks. 

Solution: (2,5,1,4,0,3) after 334 contradictions and 64 backtracks. 

Solution: (3,0,4,1,5,2) after 408 contradictions and 79 backtracks. 

Solution: (4,2,0,5,3,1) after 602 contradictions and 118 backtracks. 

Total of 742 contradictions and 149 backtracks. 

DONE 

(queens 8) 

Solution: (0,4,7,5,2,6,1,3) after 763 contradictions and 105 backtracks. 

[Ninety solutions omitted.) 

Solution: (7,3,0,2,5,1,6,4) after 12901 contradictions and 1852 backtracks. 

Total of 13664 contradictions and 1965 backtracks. 

DONE 

The two solutions for N — 4 are: 
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The trouble with chronological backtracking is that often choices are undone because of 
failures that did not (necessarily) stem from those choices. Suppose, for example, that for the 6 
queens problem queens have been successfully placed in the first four rows, and a choice is to be 
made for the last row: 



None of the squares of the last row is a valid place for a queen. Under a chronological 
backtracking regime, this failure will first cause a new choice for the queen in the second-to-last 
row. This is somewhat paradoxical, as the configuration for the first four rows collectively kills 
all squares of the last row, and so cannot appear in any valid solution, while the queen in the 
penultimate row can appear in that column in a valid solution! 

Another problem with chronological backtracking is that when a failure occurs all information 
as to why that failure occurred is thrown away. [Sussman 1972] In the context of the N queens 
problem, it can well occur that a large scries of configurations for the last several rows is tried and 
discarded, then failure causes one queen in an early row to be nudged over, and then many of the 
same configurations of the last several rows must be investigated once again—even if their failure 
had not depended on the queen that got nudged! 

flic I ISP program of Table 5-18 examines eighteen invalid board positions before finding 
a solution. These are shown in Figure 5-8. The small dark circles indicate queens. A line 
drawn between two queens indicates a conflict on a column or diagonal. A light circle around a 
queen indicates the culprit—the one which will be changed as a result of the contradiction (under 
chronological backtracking, the culprit is always the last queen placed). A bold circle around a 
queen indicates an indirect culprit—a queen that must be moved because all die choices for the 
previous culprit had been exhausted. 

The contradiction in situation (g) is the same as that in situation (c). This contradiction had to 
be rediscovered when the queen in the second row was moved, even though that queen had had 
nothing to do with the contradiction. There are no other examples of this in the N — 4 case, but 
for large N it happens quite frequently. 
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(variable qO) (variable ql) (variable q2) (variable q3) ;variables 
(create eOl equality) ;column constraints 

(create e02 equality) 

(create e03 equality) 

(create el2 equality) 

(create el3 equality) 

(create e23 equal ity) 

(== (the a eOl) qO) (== (the b eOl) ql) (== (the p eOl) (constant 0)) 

(== (the a e02) qO) (== (the b e02) q2) (= = (the p e02) (constant 0)) 

(=- (the a e03) qO) (== (the b e03) q3) (== (the p e03) (constant 0)) 

(== (the a el2) ql) (== (the b el2) q2) (== (the p el2) (constant 0)) 

(== (the a el3) ql) (== (the b el3) q3) (== (the p el3) (constant 0)) 

(=- (the a e23) q2) (== (the b e23) q3) (== (the p e23) (constant 0)) 

Tabu*: 5-J9. Constraints for the Four Queens Problem (i). 


(create xeOl equality) (create xaOl adder) ;northwest-to-southeast 

(create xe02 equality) (create xa02 adder) ; diagonal constraints 

(create xe03 equality) (create xa03 adder) 

(create xel2 equality) (create xal2 adder) 

(create xel3 equality) (create xal3 adder) 

(create xe23 equality) (create xa23 adder) 

(== (the a xaOl) qO) (== (the c xaOl) ql) (== (the b xaOl) (the a xeOl)) 

(== (the a xa02) qO) (== (the c xa02) q2) (the b xa02) (the a xe02)) 

(== (the a xa03) qO) (== (the c xa03) q3) (== (the b xa03) (the a xe03)) 

(== (the a xal2) ql) (== (the c xal2) q2) (== (the b xal2) (the a xel2)) 

(== (the a xal3) ql) (== (the c xal3) q3) (== (the b xal3) (the a xel3)) 

(== (the a xa23) q2) (== (the c xa23) q3) (== (the b xa23) (the a xe23)) 

(== (the b xeOl) (constant 1)) (== (the p xeOl) (constant 0)) 

(== (the b xe02) (constant 2)) (== (the p xe02) (constant 0)) 

(= = (the b xe03) (constant 3)) (== (the p xe03) (constant 0)) 

(== (the b xel2) (constant 1)) (== (the p xel2) (constant 0)) 

(== (the b xel3) (constant 2)) (== (the p xel3) (constant 0)) 

(== (the b xe23) (constant 1)) (== (the p xe23) (constant 0)) 

Tabu* 5-20. Constraints for the Four Queens Problem (ii). 
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(create yeOl equality) (create yaOt adder) ;southwest-to-northeast 

(create ye02 equality) (create ya02 adder) ; diagonal constraints 

(create ye03 equality) (create ya03 adder) 

(create yel2 equality) (create yal2 adder) 

(create yel3 equality) (create yal3 adder) 

(create ye23 equality) (create ya23 adder) 

(== (the a yaOl) qO) (== (the c yaOl) ql) (== (the b yaOl) (the a yeOl)) 

(== (the a ya02) qO) (-= (the c ya02) q2) (== (the b ya02) (the a ye02)) 

(== (the a ya03) qO) (== (the c ya03) q3) (== (the b ya03) (the a ye03)) 

( = = (the a yal2) ql) (= = (the c ya 12) q2) ( = = (the b yal2) (the a yel2)) 

(== (the a yal3) ql) (== (the c yal3) q3) (== (the b yal3) (the a yel3)) 

(== (the a ya23) q2) (== (the c ya23) q3) (== (the b ya23) (the a ye23)) 

(== (the b yeOl) (constant -1)) (== (the p yeOl) (constant 0)) 

(== (the b ye02) (constant -2)) (== (the p ye02) (constant 0)) 

(== (the b ye03) (constant -3)) (== (the p ye03) (constant 0)) 

(== (the b yel2) (constant -1)) (== (the p yel2) (constant 0)) 

(== (the b yel3) (constant -2)) (== (the p yel3) (constant 0)) 

(== (the b ye23) (constant -1)) (== (the p ye23) (constant 0)) 

Table 5-21. Constraints for the Four Queens Problem (iii). 


(== qO (oneof '(0 1 2 3))) ;assumptions 

(== ql (oneof '(0 1 2 3))) 

(== q2 (oneof '(0 1 2 3))) 

(== q3 (oneof '(0 1 2 3))) 

Tabl e 5-22. Constraints for the Four Queens Problem (iv). 
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Figure 5-9. Constrainl Network for the Four Queens Problem. 
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Table 5-19, Tabic 5-20, Tabic 5-21, and Table 5-22 show the constraints for the case of four 
queens, flic variables qO, ql, q2, and q3 represent the column numbers of the queens in rows 
0, 1, 2, and 3, respectively. The equalities e mn have their p pins equated to zero, and so require 
that q m and q n be different, for each pair //?, n. The equalities xe/zz/z and the adders xa mn 
enforce the relationships q/z—qzz ^ n — m; similarly, the equalities ye//?/z and the adders ya//z/z 
enforce the relationships q/z — qzz^ m-n. Flic constraints arc diagrammed in Figure 5-9. 

Running this constraint network causes twelve contradictions to occur before a valid situation 
is achieved (valid situations of course constitute solutions to the problem). Flic sequence of situa¬ 
tions considered is shown in Figure 5-10. It initially follows the same sequence of situations as in 
Figure 5-8, except that situation (g) is skipped over (because that contradiction had been explored 
already, and the record shows that it is independent of ql). Note, however, that unlike the LISP 
program of Table 5-18, the constraint system does not guarantee to check the constraints in any 
particular order. Flic lisp program always finds a contradiction with the most recent already placed 
queen that conflicts, because it searches the rows in that order. The constraint language does not 
specify any temporal ordering, and the system is free to check the constraints in any order (or even 
in parallel). Finis, for example, in situation (i) the system happened to record a conflict between q3 
and ql rather than between q3 and q2. Hither conflict is an equally good reason for rejecting the 
situation. Similarly, in situation (k) the system noted a contradiction between q3 and qO where 
the lisp program had seen a conflict between q3 and ql. Moreover, in situation (k) the lisp 
program chose q2 as the indirect culprit, because it must always retract the most recent choice, 
whether relevant or not; but the constraint system was free to choose any previous relevant choice 
as the culprit, and in fact it scrcndipitously chose qO, producing situation (x). From there it was 
only two more steps to a solution. (Note that a situation (z) with q3 = 1 was skipped over because 
of the contradiction previously recorded for situation (i).) 

The trace output from the run is given here in condensed form without commentary. Trace 
messages concerning awakening of devices and removing of values have been eliminated, as have 
messages saying that devices computed values for their parts, except that those concerning the 
oneof cells have been retained. 


|<0NE0F-889:0NE0F-889> computed 0 for its part PIN. 

|<0NE0F-892:0NE0F-892> computed 0 for its part PIN. 

(Contradiction in <E01:EQUALITY-619> among these parts: P = 0, A=0, B = 0; 

| it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

|Deeming 0 in CELL-894 (computed by rule ONEOF-RULE) to be the culprit. 

|The set CELL-662 = 0, (THE PIN ONEOF-889) = 0, (THE PIN ONEOF-892) = 0 is no good. 
|Retracting the premise <CELL-894 (PIN of ONEOF-892): 0>. 

|<0NE0F-892:0NE0F-892> computed 1 for its part PIN. 

[Contradiction in <XE01:EQUALITY-673> among these parts: P=0, A=l, B=l; 
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| it calculated 1 for P from the others by rule EQUALITY-RULE-16. 
|Deeming 1 in CELL-894 (computed by rule ONEOF-RULE) to be the culprit. 
|The set CELL-758 = 1 , CELL-760 = 0, (THE PIN 0NE0F-889) = 0, 

| (THE PIN ONEOF-892)=1 is no good. 
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Retracting the premise CCELL-894 (PIN of 0NE0F-892): 1>. 

CONEOF-892:0NE0F-892> computed 2 for its part PIN. 

CONEOF-895:ONEOF-895> computed 0 for its part PIN. 

Contradiction in <E02:EQUALITY-626> among these parts: P = 0, A=0, B = 0; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 0 in CELL-897 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-664 = 0, (THE PIN ONEOF-889) = 0, (THE PIN 0NEOF-895)=0 is no good. 
Retracting the premise <CELL-897 (PIN of 0NE0F-895): 0>. 

<0NE0F-895:ONEOF-895> computed 1 for its part PIN. 

Contradiction in <YF12:EQUALITY-823> among these parts: P=0, A=-l, B=-l; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 1 in CELL-897 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-878 = -l, CELL-880 = 0 , (THE PIN 0NE0F-892) = 2, 

(THE PIN 0NE0F-895)=1 is no good. 

Retracting the premise <CELL-897 (PIN of ONEOF-895): 1>. 

<0NE0F-895:ONEOF-895> computed 2 for its part PIN. 

Contradiction in <XE02:EQUALITY-687> among these parts: P=0, A=2, B=2; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 2 in CELL-897 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-762=2, CELL-764=0, (THE PIN 0NE0F-889)=0, 

(THE PIN ONEOF-895)=2 is no good. 

Retracting the premise <CELL-897 (PIN of ONEOF-895): 2>. 

<0NE0F-895:ONEOF-895> computed 3 for its part PIN. 

Contradiction in <XE12:EQUALITY-715> among these parts: P = 0, A=l, B = 1; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 3 in CELL-897 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-770=1, CELL-772=0, (THE PIN ONEOF-892)=2, 

(THE PIN ONEOF-895)=3 is no good. 

Retracting the premise <CELL-897 (PIN of ONEOF-895): 3>. 

All of the values (0123) for (THE PIN ONEOF-895) are no good. 

Deeming 2 in CELL-894 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-664=0, CELL-762=2, CELL-764=0, CELL-770=1, CELL-772=0, 

CELL-878 = -l, CELL-880 = 0 , (THE PIN 0NE0F-889 ) = 0, 

(THE PIN ONEOF-892)=2 is no good. 

Retracting the premise <CELL-894 (PIN of ONEOF-892): 2>. 

<0NE0F-892:ONEOF-892> computed 3 for its part PIN. 

<0NE0F-895:ONEOF-895> computed 1 for its part PIN. 

<0NE0F-898:0NE0F-898> computed 0 for its part PIN. 

Contradiction in <YE23:EQUALITY-851> among these parts: P = 0, A=-l, B =-1; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 0 in CELL-900 (computed by rule ONEOF-RULE) to be the culprit. 

The set CELL-886 = -l, CELL-888 = 0, (THE PIN ONEOF-895 ) = 1, 

(THE PIN ONEOF-898)=0 is no good. 

Retracting the premise <CELL-900 (PIN of 0NE0F-898): 0>. 

<0NE0F-898:0NE0F-898> computed 1 for its part PIN. 

Contradiction in <YE13:EQUALITY-837> among these parts: P=0, A=-2, B=-2; 

it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

Deeming 1 in CELL-900 (computed by rule ONEOF-RULE) to be the culprit. 
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;I The set CELL-882 = -2, CELL-884=0, (THE PIN ONEOF-892) = 3, 

; | (THE PIN 0NE0F-898) = 1 is no good. 

;|Retracting the premise <CELL-900 (PIN of ONEOF-898): 1>. 

;|<ONEOF-898:ONEOF-898> computed 2 for its part PIN. 

;|Contradiction in <XE23:EQUALITY-743> among these parts: P = 0, A=l, B =1; 

;| it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

;|Deeming 2 in CELL-900 (computed by rule ONEOF-RULE) to be the culprit. 

;j The set CELL-778 = 1, CELL-780 = 0, (THE PIN 0NE0F-895) = 1, 

; | (THE PIN ONEOF-898) = 2 is no good. 

;|Retracting the premise <CELL-900 (PIN of ONEOF-898): 2>. 

;|<ONEOF-898:ONEOF-898> computed 3 for its part PIN. 

; | Contr ad i ct i on in <XE03 : F.QUALITY-701> among these parts: P = 0, A=3, B = 3 ; 

;| it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

;|Deeming 3 in CELL-900 (comp.uted by rule ONEOF-RULE) to be the culprit. 

; | The set CELL-766 = 3, CF.LL-768 = 0, (THE PIN ONEOF-889) = 0, 

;| (THE PIN ONEOF-898)=3 is no good. 

;|Retracting the premise <CELL-900 (PIN of ONEOF-898): 3>. 

;|A11 of the values (0 12 3) for (THE PIN ONEOF-898) are no good. 

;|Deeming 0 in CELL-891 (computed by rule ONEOF-RULE) to be the culprit. 

;|The set CELL-766=3, CELL~768=0, CELL-778=1, CELL-780=0, CELL-882=-2, 

;| CELL-884=0, CELL-886=-l, CELL~888=0, (THE PIN ONEOF-889)=0, 

; | (THE PIN ONEOF-892) = 3, (THE PIN 0NE0F-895)=1 is no good. 

;|Retracting the premise <CELL-891 (PIN of ONEOF-889): 0>. 

;|<0NE0F-889:0NE0F~889> computed 1 for its part PIN. 

; | Contradict ion in <E02: EQUAL.ITY-626> among these parts: P = 0, A=l, B=l; 

;j it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

;|Deeming 1 in CELL-897 (computed by rule ONEOF-RULE) to be the culprit. 

;|The set CELL-664=0, (THE PIN ONEOF-889)=1, (THE PIN 0NE0F-895)=1 is no good 
;(Retracting the premise <CELL-897 (PIN of ONEOF-895): 1>. 

;|<ONEOF-895:ONEOF-895> computed 0 for its part PIN. 

;|<ONEOF-898:ONEOF-898> computed 0 for its part PIN. 

;(Contradiction in <E23:EQUALITY-654> among these parts: P = 0, A = 0, B = 0; 

;| it calculated 1 for P from the others by rule EQUALITY-RULE-16. 

;|Deeming 0 in CELL-900 (computed by rule ONEOF-RULE) to be the culprit. 

; |The set CELL-672 = 0, (THE PIN ONEOF-895) = 0, (THE PIN ONEOF-898)=0 is no good 
;|Retracting the premise <CELL-900 (PIN of ONEOF-898): 0>. 

;|<ONEOF-898:ONEOF-898> computed 2 for its part PIN. 

DONE 

This example shows that a dependency-directed backtracking system is at least potentially 
much more efficient than a chronological backtracking system. Of course, this run was a little lucky; 
it could just as easily have followed the same path as the lisp program, skipping only situation 
(g). If, however, there were a higher-level decision function controlling which constraints to try 
first, then the system might always perform much better. (Thus we arc lead to the idea of meta¬ 
constraints, for controlling the operations of the constraint interpreter.) Suppose, for example, that 
a dependency-directed backtracking system for the N queens problem were always to obey these 
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additional efficiency heuristics: 

• The first k queens must be validly placed before trying to place queen k -f- 1. (The constraint 
system happened to behave in this manner for the previous example, but the constraint lan¬ 
guage docs not guarantee to try the assumptions in a nested-loop order. The system is in 
principle free to try assumptions in any order—but this fact is being suspended as a heuristic 
here.) 

• When checking a placement for a queen and it conflicts with more than one previously placed 
queen, the least recently placed conflicting queen should be held responsible for the conflict. 
(This is equivalent to checking previous queens in the reverse of the order used by the lisp 
program.) 

• When a culprit must be chosen, always choose the most recently placed queen of those respon¬ 
sible for the contradiction (according to the records). 

If these ordering heuristics arc followed, then sixteen invalid positions arc tried before a solution is 
found. 

To point up once more the need for explanation mechanisms to exploit the nogood sets, here 
are given the explanations for the values of qO, ql, q2,and q3 at the end of the above run. 


(what qO) 

;The value 1 in CELL-612 was computed in this way: 
; QO <- (ONEOF (0 12 3)) 

OKAY? 


(what ql) 

;The value 3 in CELL-614 was 
; Ql <- (ONEOF (0 1 2 3)) 
OKAY? 

(what q2) 

;The value 0 in CELL-616 was 
; Q2 *- (ONEOF (0 12 3)) 
OKAY? 


(what q3) 

;The value 2 in CELL-618 was 
; Q3 <- (ONEOF (0 1 2 3)) 
OKAY? 


computed in this way: 


computed in this way: 


computed in this way: 


These explanations are singularly unsatisfying: they imply “I just guessed them.” This is partly 
true, but foils to take into account the additional constraints imposed and the tremendous computa¬ 
tional effort invested in satisfying them. 

This entire example has assumed that the cost of avoiding examining a position by using 
nogood sets is less than the cost of just generating the position and checking it. This may not be the 
case for this example w'ith this implementation of the constraint system. However, nogood sets can 
save a great deal when the cost of generating and checking a position is large. They can also save a 
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great deal when not all the choices arc directly connected to each other. In the N queens problem, 
every choice interacts with every other choice. If each choice were to interact with only some other 
choices, then nogood sets can eliminate many more cases. 


5.5. Discussion of the Assumption and Nogood Set Mechanisms 

As of the end of Chapter Four, before the assumption mechanisms were introduced, the con¬ 
straint system strove to compute the largest possible set of values that could be both consistently 
and detcrminatcly asserted. Consistency means that no constraints are violated; dcterminacy means 
that no arbitrary choices on the part of the system arc involved—a computed value for a node must 
be the case, and no other value will do for that node. Any value that is forced is asserted, and only 
those that are forced. Thus the system would conservatively compute a minimal maximal set of 
values; let us call this the set of required values. 

Assumption mechanisms allow a constraint network to compute a larger set of values. One 
could imagine a constraint system that would automatically make assumptions about the values of 
nodes when no forced values can be computed for them. Such a system would endeavor to find 
consistent values for the greatest possible number of nodes, in some sense. Such a set of values 
would perforce contain the set of required values as a subset. Thus we can say that an assumption 
mechanism tries to find consistent extensions of the set of required values. 

One difficulty with a general, domain-independent automatic assumption mechanism is that it 
may well thrash, perhaps even trying to solve the unsolvable. It is all too easy to set up Diophantine 
equations whose solutions involve extremely large integers that would be infeasible to guess. 

The mechanism we have exhibited here is a compromise between a fully automatic assump¬ 
tion mechanism and none at all. The assumption constructs added to the language permit the user 
to explicitly advise the system on which extensions to pursue and what values to try. The assume 
construct in effect says, ‘The extension for which this node has value n may be interesting, if it 
is consistent.” By connecting several assume cells together, a number of alternative extensions 
involving the same node can be suggested, and the system can choose among them. In this way 
which nodes to consider for extension arc explicitly indicated, and the search space for each node 
delineated. The oneof construct adds a little more power by providing a total predicate for the 
search possibilities. This gives one the leverage to perform exhaustive case analysis and perform 
resolution on nogood sets. 

For some purposes it might be useful to separate two properties of the oneof construct: the 
limiting of the value space to a definite finite set, and the advice to try an extension by assuming 
one. If there were a construct val uespace for the former property alone, then the effect of 

(== x (oneof ' ( a b c ...))) 
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(defprim firstoneof (pin)) 

(progn 'compile 

(push 'firstoneof-rule (ctype-rules firstoneof)) 

(defprop firstoneof-rule () trigger-names) 

(defprop firstoneof-rule (pin) output-names) 

(defprop firstoneof-rule firstoneof tentative) 

'(firstoneof rule)) 

(defun firstoneof (valuelist) 

(let ((a (gen-constraint firstoneof ()))) 

(self (con-name a) (con-id a)) 

(setf (con-info a) valuelist) 

(awaken a) 

(the pin a))) 

(defprop firstoneof ((pin (firstoneof !))) treeforms) 

Compare this with Table 5-3. 

Tabu' 5-23. Implementation of the firstoneof Construct. 


could be achieved by 

(== x (valuespace '(a b c ...))) 
(== x (assume a)) 

(== x (assume b )) 

(== x (assume c)) 


The latter states that it is an error for x to take on a value not among & b, c ,..., and separately that 
each of these value may be considered for constructing extensions. There might be uses for wanting 
to advise the system that only some of the values are useful to try for extensions. 

flic notion of valuespace itself can be divided into two parts. One part is triggered when 
a new value is computed, and raises a contradiction if the value is not in the set. The other part 
is triggered when a value is forgotten, and examines nogood sets to sec whether resolution can be 
performed. An instance of the first part is built into the gate and equal ity primitives of'fable 
2-7 (page 53) and Table 3-5 (page 79): each has a rule which signals a contradiction if the p pin has 
a value other than 0 or 1. However, the rule has no provision for making a deduction by resolution 
if both 0 and 1 arc tried and fail. There seems to be no gain in having one part without the other. 

The assumption mechanisms given here provide no means for ordering values to be tried, 
either locally (at a single node) or globally (among several nodes). The oneof construct, as imple¬ 
mented here, happens to try the values in the order stated. However, the definition of the construct 
at the user language level does not guarantee this; the system is free to try values in any order. A 
slightly different distinction is that the oneof construct docs not guarantee always to assert the 
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earliest consistent value in the list. When it is asked to assume a new value, it happens (in this 
implementation) to scan the list in order, looking for possibilities. However, if the third value 
in the list is consistently asserted, and then a nogood set for some reason forbids the first value 
in the list to be consistently asserted, oneof will not notice this. The possibly useful construct 
firstoneof would notice this, and strive always to assert earlier values in the list if possible. 
That is, it would undertake always to construct an extension using the earliest possible value in its 
list. As an example, consider two parallel examples using oneof and f i rstoneof. In each case 
an adder is created, the a and b pins equated to 1, the c pin equated to an assumption, and then 
the b pin disconnected from its constant. 

(create foo adder) 

<FOO:ADDER-385> 

(== (the a foo) (constant 1)) 

DONE 

(== (the b foo) (constant 1)) 

DONE 

( = = (the c foo) (oneof '(0 1 2 3))) 

DONE 

(what (the c foo)) 

;The value 2 in CELL-391 was computed in this way: 

; (THE C FOO) «- (ONEOF (0 1 2 3)) 

OKAY? 

(disconnect (the b foo)) 

DONE 

(what (the c foo)) 

;The value 2 in CELL-391 was computed in this way: 

; (THE C FOO) <- (ONEOF (0 1 2 3)) 

OKAY? 

(what (the b foo)) 

;The value 1 in CELL-389 was computed in this way: 

; (THE B FOO) «- (- (ONEOF (0 1 2 3)) 1) 

OKAY? 

The value 2 remains on the c pin—the oneof cell is happy with any of its four values. On the 
other hand: 

(create bar adder) 

<BAR:ADDER-400> 

(== (the a bar) (constant 1)) 

DONE 

(== (the b bar) (constant 1)) 

DONE 

(== (the c foo) (firstoneof '(0 1 2 3))) 

DONE 

(what (the c bar)) 

;The value 2 in CELL-406 was computed in this way: 
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(defun firstoneof-rule (*me*) 

(let ((*rule* ' firstoneof-rule) 

(pin-cell (the pin *me*))) 

(let ((values (con-info *me*))) 

(do-named 1oop-over-possibi1ities 
((v values (cdr v)) 

(killers ' ())) 

((null v) 

(ctrace "All of the values ~S for ~S are no good." 
values 

(cel 1-goodname pin-cell)) 

(let ((losers '())) 

(dolist (killer killers) 

(dolist (x (cdr killer)) 

(or (eq (car x) (cell-repository pin-cell)) 

(let ((cell (if (rep boundp (car x)) 

(rep-supplier (car x)) 

(car (rep-cells (car x)))))) ;??? 

(or (memq cell losers) 

(push cell losers)))))) 

(process-contradiction losers)) 

(firstoneof-rule *me*)) 

(do-named outer-loop 

((x (cdr (assoc (car v) (node-nogoods pin-cell))) 

(cdr x))) 

((null x) 

(cond ((node-boundp pin-cell) 

(and (not (equal (node-contents pin-cell) (car v))) 

(cond ((eq (node-supplier pin-cell) pin-cell) 

( retract pin -cel 1) 

(setc pin (car v))) 

(t (contradiction pin))))) 

(t (setc pin (car v)))) 

(re turn-f rom loop-over-possibilities)) 

(do-named inner-loop 

((c (cdar x) (cdr c))) 

((null c) 

(push (car x) killers) 

(return-from outer-loop)) 

(and (not (eq (caar c) (cel 1-repository pin-cell))) 

(or (not (rep-boundp (caar c))) 

(not (equal (rep-contents (caar c)) (cdar c)))) 

(return-from inner-loop)))))))) 

Compare this with Table 5-4. 

Table 5-24. The Rule for firstoneof. 


; (THE C BAR) (FIRSTONEOF (0 1 2 3)) 

OKAY? 

(disconnect (the b bar)) 

DONE 

(what (the c bar)) 

;The value 0 in CELL-406 was computed in this way: 
; (THE C BAR) «- (FIRSTONEOF (0 1 2 3)) 
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Figure 5-11. Constraint Network for Making a General Choice. 


OKAY? 

(what (the b bar)) 

;The value -1 in CELL-404 was computed in this way: 

; (THE B BAR) «- (- (FIRSTONEOF (0 1 2 3)) 1) 

OKAY? 

When the constant 1 was removed from (the b bar), the f i rstoneof cell noted that the 
value 0 was no longer forbidden, and retracted the value 2 to try the value 0 again, which in fact 
worked. Thus f i rstoneof always tries to use the first consistent value in its list. The code for 
f i rstoneof (a trivial modification to that for oneof) appears in Table 5-23 and Table 5-24. 

One might wish to have a more general oneof mechanism then selection from a set of con¬ 
stants. It would be useful to have a kind of device called, say, choice, with pins named x, aO, 
al,..., an (for (n -f- l)-way multiplexing); the intent is that x would be connected to exactly one 
of the other pins. Observe, however, that this is a special case of an even more general and useful 
device, which we might call a multiplexor (by analogy with hardware) or a case (by analogy 
with software) device, with pins named x, aO, al, ..., an; s must be an integer from 0 to n, 
and x is connected to the s’th a pin. Then by connecting a ceil (oneof '(0 1 2 ... n)) 
to the s pin, we get a choice box. A multiplexor is then easily constructed from equal i ty and 
gate devices, and so the general choice construction can be simulated as in Figure 5-11. If all 
the gate devices arc changed to equal i ty devices, then the individual choices arc additionally 
constrained to be distinct. 
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In aequora elucet sol 
Effulgens plurimum: 

Quam maxime is tentat ut 
Sit mare placidum — 

Absurdum quidem. quod hoc fit 
Ad noctis medium. 

—Lewis Carroll 

Aliciae per Speculum Tran situs 

Translation by Clive Harcourt Carruthers (1966) 


Horn cue lava per protiniam teremeles 
l.imag'des teretant el quoque gyrirotant. 

Sunt tenuiscopi macriUi; saepeque virci 
iido mi pa l i etiam vocibus eruditant. 

—Lewis Carroll 
"Taetriferoeias” 

Aliciae per Speculum Transitus 

Translation by Clive Harcourt Carruthers (1966) 


Howl ,and Owl: We’ve got to use the old savvy, the know-how , the tnoxie , the mother-wit , 
ars celare artem\ 


Churchy La Fhmml: You said it! 

Howland Owl: Thank you. 

CHURCHY La Fhmml: [Aside] Tin behind him as least one hunderd poor cent. 

Seminole Sam: I’m behind him about seven miles... Whal'd he say? 

Churchy La Femme: Who knows ... ? It was in Latin an’ that is recommendation enough for 

me. 

SEMINOLE Sam: Wonder what language the Romans used for the old 14 karat bamboozle? 

—Walt Kelly 
The Togo Party 


Sic omelet magnolia in tabasco bunion. 

—Rube Goldberg 
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With his filibeg fair filligreed 
With finest filiform. 

He fleetly footed J'roo an' fro 
The figwort in the storm. 

A flaughl of borealis and a 
Firkin fine of fat 
Was Jimbricated on the fringe 
Of Frelinghuysen's hat. 

-Wall Kelly (1952) 
/ Go Togo 
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S N previous CHAPTERS wc have concentrated on developing, in as simple a manner as possible, 
the fundamental concepts of a constraint language and means of implementing them. The 
development has been linear; at each step we made incremental improvements, building on pre¬ 
vious work. In this chapter wc will undertake a complete revision of the implementation. A few 
new “user features” will be added, but the primary emphasis will be on implementation techniques 
designed to enhance the efficiency of the system. 

A summary of the changes and improvements made in the new version to be presented in this 
chapter: 

• Where possible, arrays will be used internally rather than lists. (The assumption is that an array 
element can be accessed in constant time by indexing, while accessing a list clement takes time 
linear in die position of the clement in the list.) 

• The pins of a constraint will be considered to constitute a “frame” or “binding contour” (these 
words arc meant only to invoke certain mental associations). The names of pins in rules will be 
“compiled out” and replaced by numeric indices into the frame. This allows a rule to access a 
pin in constant time rather than by using the 1 ookup operation on entry to the rule. 

• When there is a reason to awaken a device, in previous versions all the rules of that device 
would be awakened. Here the rules will be categorized according to pin number, and the 
awakening circumstances categorized as “added value”, “forgotten value”, or “nogood set 
changed”. This will provide a two-dimensional access to a prc-computed bucket of applicable 
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rules to be awakened. Such a bucket will be potentially much smaller than the total set of rules 
associated with a device. 

• The control structure of previous systems was based on explicit LISP function calls, with the 
result that the order in which things were done depended on the order in which procedures of 
the implementation invoked others. To reduce this explicit dependence, a task queue control 
structure will be used. Hach task can perform some work, and in the process enqueue more 
tasks. A strong invariant to be enforced is dial when a task completes any queued task may 
correctly be performed next. Other strong invariants can be established about the state of the 
constraint network data structures as of the time of choosing the next task to perform. 

• Not only rules but also contradictions are treated as tasks to be queued. This allows us to make 
some strong claims about the state of the system when it is contradictory. In particular, we 
will be able to show that functions such as d isconnect and what will produce meaningful 
results when applied while the network is in a contradictory state. This is easier to show because 
the relevant state is made explicit as LISP data structures, rather than having part of it implicit in 
the internal LISP program state. 

• The introduction of the task queue discipline allows certain efficiency heuristics to be intro¬ 
duced by having multiple queues with various priorities. Certain kinds of rules can be given 
high or low priority, for example. 

• In the previous versions, a rule could often be run many times because it was awakened for 
several different reasons. However, once it has been decided to run a rule for whatever reason, 
the computation performed by the rule does not depend (directly) on that reason. In this im¬ 
plementation, a bit will be set when a rule is enqueued for a device, and reset when the rule is 
run; a rule is not enqueued if its bit is already set. In this way between the time a rule is queued 
and the time it is run, it will not be enqueued redundantly. 

• In this implementation multiple sources of support for the value of a node will be recorded. 
Also, the history of cquatings will be recorded, so that explanations can say which equatings 
were involved in a computation. (This could lead eventually to automatic retraction of equatings 
as well as of default values, but that will not be done here.) This is all accomplished by retaining 
the cell/repository node structure that has been used so far, but moving some of the repository 
fields (contents, boundp, rule) into the cells, so that each cell can record its own value. 

• At first there were constant cells, and then both constant and default cells. Here we 
will introduce a three-level hierarchy of valued cells: constant, default, and parameter, 
'this will allow certain heuristics to speed up processing of nogood sets. 

• Rather than having a variety of idiosyncratic notations for the various algebraic expressions for 
a device, a general notation will be introduced for writing any arbitrarily rooted sub-tree of a 
constraint network. 

• Some new user facilities for manipulating the network will be introduced, such a detach and 



§ 6.1 


The New Improved Language 183 


disequate, to be explained below. 

• The situation where the user re-uses a variable name for sonic other purpose (for example, 
saying (create foo adder) some time after saying (vari abl e f oo)) will be dealt with 
explicitly and handled cleanly. 


6.1. The New Improved Language 

'The user interacts with the system by typing a sequence of statements. Rach statement can be 

one of these: 

► (create constraint-name constraint-type) creates a constraint instance. Thereafter the 
global name constraint-name represents that instance. 'This also implicitly brings into existence 
a collection of variables (pins of the constraint) named by using the the construct (described 
below). 

► (variable variable-name) declares a global variable. 

► (des t roy global-name) causes the name global-name no longer to represent anything. If the 
name had most recently been a global variable, then that variable no longer exists, and it is as if 
all equatings of that variable had never been made. If the name had most recently represented a 
constraint instance, then it is as if that instance had never existed, and as if any equatings of its 
pins had never been made. 

► ( = = thing-1 ihing-2) equates two quantities. 

► (disequate thing-l thing-2) makes it as if any equating of thing-/ to thing-2 had never 
taken place. It doesn’t matter whether there actually had previously been such an equating. 

► (detach thing) makes it as if any equatings of thing to anything else had never been made. 
However, thing itself still exists, so this is not the same as destroying it. Also, a pin of a 
constraint can be detached but not destroyed. 

► (disconnect thing) makes it as if any equatings of thing had never been made, but also 
as if the things that thing had been equated to had all been equated to each other. Thus if a 
had previously been equated to b, c, and d, and d had been equated to e and f, then after 
(disconnect a) the variable a still exists, not equated to anything; and b, c, and d are all 
mutually equated; and d is still equated to e and f, but e and f are not (directly) equated to 
b and c. 

► (dissolve thing) makes it as if every thing equated to th i ng, directly or indirectly, had 
not been equated to anything. It is like detaching everything equated (directly or indirectly) to 
thing. 

► ( retract thing) causes the source of the value in thing to be forgotten. This is useful only 
if this source is a default or parameter (sec below); it makes it as if the default or 



184 ChaptkrSix 


Kl'JfCIKNCY 


pa name te r had been disconnected (more or less). 

► (change thing integer) causes the source of the value in thing to be changed to integer. 
This only works if the source is a default or parameter (see below); it makes it as if the 
default or parameter had originally had integer as its value. 

► (disallow thing-1 thing-2 ... thing-n) indicates that the combination of premise values 
on which the specified things arc based is arbitrarily disallowed. 1 

► thing makes inquiry as to the value of the thing. The precise nature of the output is not specified 
here. 

► (why thing) gives local information as to why thing does or docs not have a value. The precise 
nature of the output is not specified here. 

► (why-ul t imately thing) gives global information as to why thing docs or docs not have a 
value. The precise nature of the output is not specified here. 

► (what thing) prints part of the network as an algebraic expression in order to explain why 
thing does or docs not have a value. The precise nature of the output is not specified here. 

The following constructs may be used to represent a thing: 

• variable-name, the name of a declared global variable. The name of a constraint instance may 
not be used—it is meaningless for this purpose. 2 A variable may not be referred to until it has 
been declared by a variable statement. 

• (constant integer), which effectively means an anonymous variable with integer as its as¬ 
sociated value. It is not permitted to retract a constant variable. 

• (default integer), which effectively means an anonymous variable with integer as its as¬ 
sociated value. A default variable is assumed not to change value very often (sec the 
change statement above), but this affects only efficiency heuristics, not die computational 
behavior of the system, the value may be retracted from a default variable. 

• (parameter integer), which effectively means an anonymous variable with integer as its as¬ 
sociated value. A parameter variable is assumed to be likely to change its value frequently 
(sec the change statement above), but this affects only efficiency heuristics, not the computa¬ 
tional behavior of the system, flic value may be retracted from a default variable. 

• (assume integer), which is like a parameter variable plus an implicit constraint that 
causes the variable to have the value integer whenever that is consistently possible. If the value 
is retracted, diis constraint may cause it to rc-appear. If there are competing assumptions (for 


1. Ihis is useful for finding more than one solution for a network; after one is found, it is disallowed to force the 
next to be found. This strategy is reminiscent of how multiple solutions are generated in PROLOG. 


2. Suppose that it were meaningful? Pursuing this thought leads to the possibility of a meta-circular constraint 
language, one in which constraints themselves arc objects of the language which can be constrained. ITiis is not 
considered in this dissertation, but the possibility is discussed in the Conclusions. 
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example, either of two assumptions may be asserted but not both at once), the choice of which 
to assert is entirely up to the system. 

• (oneof integer-list ), which is like a parameter variable plus an implicit constraint that 
causes the variable to have as its value one of the integers in integer-list (a contradiction occurs if 
this is not possible). If one of the integers in the list is retracted, the implicit constraint requires 
another to appear in its place. 

• ( f i rstoneof integer-list ), which is like a oneof variable except that the earliest value in 
the list that can consistently be the value of the variable must actually be the value of the vari¬ 
able. Even if the variable consistently has a value, it may be retracted by the implicit constraint 
and a new value (occurring earlier in the list) substituted. 

• (the pin-name constraint-name) , which means the pin pin-name of the constraint constraint- 
name. The pin-names which may be used by a constraint are determined by the type of the con¬ 
straint used in the create statement which created the constraint. A pin may not be referred 
to until its constraint has been declared in a create statement. 

The constraint-types provided by the language, with their associated pin names and a short 


description of their purpose, are: 

adder {a, b, cj 

c — a -f- b. 

multiplier {a, b, c} 

c = a X b. 

maxer {a, b, c} 

c — max(a, b). 

minner {a, b, c) 

c = min(a, b). 

equal i ty {p, a, b} 

p <=> (a = 6), where the truth value for p is represented by 0 for 
false or 1 for true. 

gate {p, a, b} 

p=> (a = b). 

lesser {a, b} 

Contradiction unless a < b. 

lesser! {p, a, b} 

p <=> lcsscr(a, 6). 

lesser? {p, a, b} 

p => lesscr(a, 6). 

?1 esser {a, b} 

Contradiction unless a < b. Also, if a is known, then a -J— 1 is 
considered a good guess for 6; and if b is known, then b — 1 is 
considered worth trying fora. 

?lesser ! {p, a, b} 

p <=> ?lesser(a, 6). 

?lesser? {p, a, b} 

p => ?lesser(a, b). 

?maxer {a, b, c} 

c = max(a, b). Also, if a is known and b is not, then a is considered 
a good guess for c, and similarly if b is known and not a. 

?minner {a, b, c} 

c = min(a, b). Also, if a is known and b is not, then a is considered 
a good guess for c, and similarly if 6 is known and not a. 

signum (s, a} 

s = signum(a); that is, s is —1, 0, or 1 according to whether a is 
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negative, zero, or positive. 

When a contradiction occurs, then the user may be asked to specify which of several 
default or parameter values to retract. The nature of this interaction is not specified here. 

This description is not complete, of course, and it speaks of “values” and “contradictions” 
without explaining them. It is not a complete description of the language, but only a syntactic 
summary with some brief indications of semantics. 

We would like the following property to be true of the constraint system, however: except 
for the ordering considerations explicitly expressed above, the order in which statements are input 
to the system makes no difference in the structure of the network constructed, and makes no 
difference in the computational results except for the eases where the system is explicitly given free 
choice among alternatives (as with competing assume constructs). A slightly different property 
is that from any input sequence of statements one can derive, using purely syntactic techniques, 
a new sequence made up only of variable, create, and == statements whuch produces a 
network of the same structure and containing the same computational values (again excepting free 
choices of the system). Moreover, all the variable statements can precede all the create state¬ 
ments, which in turn can precede all the == statements. Indeed, within each group the statements 
can be arbitrarily re-ordered, for example lexicographically. 


6.2. The New Improved Techniques 

In this section we examine the techniques and data structures to be used in the implementa¬ 
tion. Actually, not all of them arc completely new, but are derived from those used in previous 
versions. 


6.2.1. Cells Explicitly Record Multiple Support and Equatings 

The exact equating specified by the user arc to be recorded in a recoverable form. To do 
this we record each equating explicitly (as discussed in §2.2.1 and shown in Figure 2-4 (page 42)a. 
Moreover, in order to be able to assign rcponsibility for propagation to specified equatings without 
creating circular explanations, a propagation path among equated cells is maintained. However, 
for speed, this path is computed once when the cells are equated, but then not actually used for 
propagating. (It’s not clear that this really buys any speed in a sequential implementation such as 
this, but in a parallel implementation this technique allows for fast broadcasting of a value newly 
arrived at a node, without sacrificing the dependency structure of the equatings.) The assumption 
behind this technique is that values change more frequently than equatings arc done and undone. 

In order that multiple support for values can be recorded, every cell can have its own value. 
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Cells which are pins of constraints can always record a value provided by a rule of the constraint, 

for example. To this end the contents, boundp, and rule components arc removed from the 

repository structure and added to each cell. 

A repository is tints now a data structure with five components: 

(a) id, a unique symbol used mostly for sorting the nodes and for debugging purposes. The LISP 
value of the id is the repository. 

(b) cells , a list of cells. A repository plus its associated cells make up a node. 

(c) supplier, one of the cells. There is always a supplier cell, whether or not any cell of the 
node has a value. (This is for purposes similar to the use of an artificial supplier in the 
tree-form-trace function of Table 3-16 (page 98).) 

(d) nopoods, a table of buckets of nogood sets, as described in §5.3. 

(e) contra, the number of cells in the node which have their own values which do not agree with 
the value claimed by the supplier. Hence if this is non-zero the node is in a contradictory state. 

A cell has ten components: 

(a) id, a unique symbol used mostly for debugging purposes. The LISP value of the id is the cell. 

(b) repository, the repository of the cell. The cell must be on the repository’s cells list. 

(c) mark, used for graph-marking algorithms. 

(d) owner, which is either a constraint (in which case the cell is a pin of the constraint), or () , in 
which case this may be a global, constant, default,or parameter cell. 

(e) name. If the owner is a constraint, then this is an integer (not a symbol as before), an index 
into the table of pins for the constraint’s type. For a global cell, this is the LISP symbol which 
is the name of the cell; the value of the lisp symbol is the cell. For constant cells this is the 
symbol constant, and for default and parameter cells this is a generated name used 
for debugging. 

(f) state, which describes whether and how the cell has a value (see below). 

(g) contents, usually the value (if any) of the cell, but sec below. 

(h) rule, the rule by which the value was computed if the cell indeed has a value, or () if the cell 
has no value. There are three artificial rules called *constant-rule*, *defaul t-rule*, 
and *paramet.er-rule*, used to distinguish constant, default, and parameters 
cells respectively. 

(i) equivs, a list of other cells of the node (members of the cells list of this cell’s repository) 
to which this cell has been explicitly equated by a == statement. Exception: if one says 
(== x x) (which is perfectly legal and meaningful, if of doubtful utility), then x will not 
appear on its own equivs list. 

(j) link, one of the cells in the equivs list, or () . The link components of the cells of a node 
describe a valid propagation pattern within the node along explicit == connections. 
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Figure 6-1. Data Structure for a Node with No Value. 
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The old boundp component of repositories in the old scheme of tilings has been replaced 
by a state component in cells. The boundp component had two states: “value” or “no value”. 
The state component has six states, and encodes whether a cell has a value and also documents 
to some extent the cell’s relationship to other cells. The information in the state component is 
partly redundant, as it encodes information obtainable from other cell components or components 
of other cells in the node. This redundancy sometimes enhances speed, and sometimes just permits 
some error checks. In any case, I believe that recording the six states explicitly aids visualization of 
what’s going on. flic six states have symbolic names; as a point of convention symbolic names here 
will begin with 

(1) @k i ng. This cell has a value (in its contents component), and is the supplier for the node. The 
rule component of the cell indicates how the value was derived. 

(2) @puppet. This cell has no value, but was arbitrarily chosen as the supplier for the node be¬ 
cause no other cell of the node has a value either. (Kvcry node has a supplier, and the supplier 
must be cither a king or a puppet.) The contents and rule components are (). 

(3) @sl ave. This cell has no value of its own. It takes on the value (if any) of the node’s supplier; 
thus if the node’s supplier is a king, then all slave cells inherit values. (If the node’s supplier is a 
puppet, then all the other cells must be slaves, and have no values, inherited or otherwise.) The 
contents and rule components are (). 

(4) @f ri end. This cell is not the node’s supplier, but it has its own value, and it is the same value 
as that of the supplier. The contents and rule component are as for a king. 

(5) @rebel. This cell is not the node’s supplier, but it has its own value, and it is not the same 
value as that of the supplier (hence the node is in a contradictory state). The contents and rule 
component are as for a king. (The contra component of a repository is simply the number of 
rebel cells in the node. There is no special way to indicate that two rebels have the same value.) 

(6) @dupe. This cell is in effect a slave to a rebel. It has no value of its own, but agrees with a 
rebel rather than with the supplier. (This situation arises only as a result of applying == to 
two nodes with differing values: one node is chosen arbitrarily to have its king and friends 
changed to rebels, and its slaves to dupes of the former king. The node can then be queued for 
contradiction processing later. Dupes tend to disappear over time.) The rule component is (), 
but the contents component is the rebel cell of which this cell is the dupe. 

Thus kings, friends, and rebels have their own values; puppets, slaves, and dupes do not. Kings and 
puppets arc suppliers; friends and slaves agree with suppliers; rebels and dupes oppose suppliers 
(necessarily kings). The cases of being a slave to a king and a slave to a puppet arc purposely not 
distinguished in the state. This means that on encountering a slave one must check the supplier; but 
then again when a puppet becomes a king it is not necessary to change the states of all cells in the 
node. This speeds up the “good” cases of propagation without contradiction. 

The link components of a node form a spanning tree for the node. The supplier of the node 
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must have () for its link, and all others must point to some other cell of the node. Consider the 
graph of explicit == connections. Then the links form a subgraph which is a strict tree. Moreover, 
the links indicate a direction for the edges (if cell x’s link is cell y, then the edge between x and y 
is indicated and directed it from x to y). Considering diesc directions, then the tree is rooted at the 
supplier and from any leaf following edges in the indicated direction will lead to the supplier. This 
property is useful for determining which equatings were responsible for a cell’s getting a value. 
(However, the value for a dupe or slave can be found quickly just by looking at the contents of 
the supplier of the repository of the cell, rather than having to follow an indefinite number of link 
edges.) 

As an example. Figure 6-1 shows a node of four cells, of which two arc global variables and 
two arc pins. None have values, so one of the pins has been arbitrarily chosen to be the puppet. 
Four equatings were done; the last (between the two variables) being redundant. Note that the link 
components converge on the puppet, which has a null link. ( The figure docs not show the pointers 
between the structures and the LISP symbols whose values are the structures; instead, the name of 
the lisp symbol is written.) 

Figure 6-2 shows the same node after the adder has computed die value 43 for its pin, and 
then later the gate also computes the value 43. Because the adder happened to compute its value 
first, it was made king. This entailed rearranging the links (actually only one) to converge on die 
king; this is noted in the figure. When the gate then computed a value, its pin became a friend of 
the king. Note that the rule components of the pins now contain rules. 

in Figure 6-3 the gate has retracted the value 43 for its pin (presumably because some premise 
was changed) and instead asserted the value 65536. This makes the gate’s pin a rebel. The links 
need not change, but the state of the gate’s pin changes to @rebel. Note that one slave’s link 
actually points to the rebel; this docs not make it a dupe, however—it still inherits die king’s value. 
The point is to do the minimum work necessary; there might actually be no equatings allowing a 
path from slave to king without going through a rebel, and yet when a rebel appears we would not 
want such slaves to become dupes because that would entail retracting the old value from the new 
dupes and their consequences and re-propagating the rebel’s value—and we should be reluctant to 
do that because, after all, it is not clear whether the rebel’s value is “correct”: it may well soon 
disappear. 


6.2.2. Constraints Use Arrays Indexed by Pin Number 

fhe previous implementations of constraint-types, constraints, and rules used lists of diings 
that took time to access. In particular, when a rule was invoked it was necessary to use lookup to 
find the pin-cells; a rule which used all the cells would take time quadratic in the number of pins to 
do this. Of course, this wasn’t so bad since the particular constraint-types provided had only a few 
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pins, but we would like not to preclude the implementation of constraint-types with many pins. 

Here wc will use records (defined types) and arrays for collections of things which must be 
random-accessed, and lists for things that must be traversed linearly anyway. Wc will make rule 
be a new data type for representing rules—property lists arc nice for fast prototyping, but not 
necessarily for fast execution. 

In the new implementation a constraint-type will be a data structure with six components: 

(a) name , a MSP symbol whioch is the name of the constraint-type. The MSP value of the symbol is 
the constraint-type structure. 

(b) vars, an array of distinct symbols. These arc the names of the pins. The array is zero-origin; the 
indices for an array of length n arc the integers from 0 to n — 1, inclusive. The position in this 
array of a pin-name is the number for that pin-name; thus wc may speak of pin-numbers. 

(c) symbol a MSP symbol used to represent constraints of this type in algebraic expressions. 
Sometimes, but not always, this is the same as the name. 

(d) added-rulcs, an array indexed by pin-number. Klcment j is a bucket (a list) of rules having 
pin j as a trigger. Thus, when pin f s node receives a new value, exactly these rules should be 
awakened. 

(c) forget-rules, an array indexed by pin-number. Klcment y is a bucket of rules having pin j as an 
output pin. When a value is forgotten for piny, exactly these rules should be awakened. 

(f) nogood-rules , an array indexed by pin-number. Klcment j is a bucket of rules having pin j as 
an output pin and which might formerly have been prevented from assciting a value for die 
pin because of a nogood set. When die status of a nogood set involving the node containing pin 
j, exactly these rules should be awakened. 

A constraint has five components: 

(a) name , the global name of the constraint. The MSP value of the name is the constraint. (The id 
component has been eliminated, as steps are taken in this implementation to ensure that the 
global name uniquely identifies the constraint.) 

(b) ctype, the constraint-type of which this constraint is an instance. 

(c) values, an array indexed by pin-number. This array is of the same length as the vars array of the 
ctype. Klcment j is a cell, pin j of this instance of the constraint-type. The owner of pin j of a 
constraint is the constraint, and the name of pin j is the integer j. 

(d) info, a slot used by certain constraint types to associate instance-specific information with each 
instance. 

(e) queued-rules, an integer, initially 0. This is used in conjunction with die id-bit component of 
rules (sec below). 

A rule has six components: 

(a) code, a MSP symbol which serves as both die name of the rule structure itself (for debugging 




purposes) and also the name of the I ISP function which implements the rule (taking advantage 
of the fact that most LISP systems, including Lisp Machine LISP, allow a name to be used 
simultaneously as a variable name and a function name without conflict). 
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(b) ctype, the constraint-type with which the rule is associated. 

(c) triggers , a list of pin-numbers of the pins which are the triggers for this rule. 

(d) outvar , the pin-number of the single pin for which this rule computes a value; or (), indicating 
that the rule never computes a value for a pin. 

(c) bits , an integer used to encode some flag bits. These flags are integers which are powers of two 
(set) or zero (clear), and bits is the sum of the flag values. (Of course, the name is suggestive 
of the fact that a two’s-complcment representation of the integers is being taken advantage 
of.) The two flags encoded here arc called ©nogood and ©nogoodbeg. If either is set, then 
it is possible for a nogood set to prevent the rule from asserting a value; such rules should 
appear in buckets of the nogood-rules array of the ctype. The ©nogoodbeg bit differs from 
the ©nogood bit in that it is very meek, and will not produce a value for a node if the node 
has a conflicting value; a simple @nogood rule is willing to assert its value boldly and cause 
a contradiction. Therefore @nogoodbeg rules are not invoked unless the output pin has no 
value (and so must beg for a value). 

(0 id-bit. an integer which is a power of two. All the rules associated with a given constraint-type 
have distinct id-bit components. This bit is used to identify whether a rule has been queued 
for processing but not yet processed. When a rule is about to be awakened on a constraint, the 
queued-rules component of the constraint is checked; if the rule's id-bit is set in the queued- 
rules , then the rule need not be queued now because that would be redundant. Otherwise, 
the rule/constraint pair is queued and bit set in the queued-rules component of the constraint. 
When a rule/constraint pair is dequeued, the bit is reset in the queued-rules component. This 
technique keeps the queues from being bloated and the system from wastcfully running the 
same rule many times. 

The reader may have noted that previously rules could in principle setc more than one pin, but 
here the definition of the outvar component implies that a rule may set at most one pin. This 
will make it easier to move some of the rule machinery out of the individual rules into a common 
processing routine. 

Figure 6-4 shows the data structures for the constraint-type ga te, whose new definition is; 
(defprim gate (p a b) 

((p) (if (or (= p 0) (= p 1)) @dismiss @lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (= a b) ©dismiss 0)) 

(b (p a) (if (= p 1) a ©dismiss)) 

(a (p b) (if (= p 1) b ©dismiss))) 

The first rule has no output pin; the second has output pin p, no input pins, and should have the 

©nogoodbeg bit set. This definition format will be discussed more thoroughly below. 
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6.2.3. Constants Are Considered an Immutable Part of the Wiring 

In this implementation it is not permitted to retract a constant. In Chapter Four it was men¬ 
tioned that the ability to retract constants is easy to provide, and so one might as well. Here there 
arc two counterarguments, one theoretical and one pragmatic—take your pick! (1) One ought to 
have a way of wiring essential constants into the network and have them considered part of the 
network structure, on a par with == connections, rather than alterable parameters. (2) If constants 
arc immutable, they can be shared. We will use a hash table to record generated constant cells so 
that if “(constant 43)is typed many times only one constant cell is generated. 

It is still useful to have two kinds of retractable valued cells, and so we call these types 
default and parameter cells. In Chapter Four, the distinction was drawn to guide a heuristic 
about which cells should be preferred for retraction. Here, the distinction will instead guide a 
heuristic about the formation of nogood sets. 


6.2.4. A Queue-Based Control Structure Aids Efficiency Heuristics 

In this implementation there are seven queues, a rather arbitrary number, to be sure. They 
arc arranged in a simple priority order as an efficiency heuristic; but again, I emphasize that a fun¬ 
damental principle of the system is that when the time comes to dequeue a task, any task from any 
queue may be validly chosen and executed; the ordering of the queues and the ordering within a 
queue affects only speed and choices explicitly reserved to the whim of the system by the language. 
The queues, in order from highest to lowest priority, are: 

(1) *contra-queue*: Outstanding contradictions to be processed. Contradiction entries are of 
three kinds. A ©node contradiction indicates that a node is in a contradictory state (has at 
least one rebel). A ©constraint contradiction indicates that a rule explicitly signalled a 
contradiction. A ©resolution contradiction indicates that a new nogood set was derived 
by resolving old nogood sets. (Note that these situations obtained at the time the entry was 
queued. By the time the entry is dequeued for processing the situation may have already been 
solved. This is legitimate and must be accounted for. If the network contains a contradiction, 
then there must be an entry for it on the queue; but not vice versa.) 

Contradictions are given highest priority because there is (probably) no point in computing 
new values from inconsistent information. However, sec the descriptions of *defer-queue* 
and * punt- queue* below. 

(2) *detector-queue*: Rules which have no output pin. Such rules are called “detectors” 
because all they can do is detect contradictions; they compute no values. Hach queue item is a 
pair of a rule and a constraint to apply the rule to. 

Detector rules are given higher priority than ordinary rules because if on the one hand there is 
no contradiction, the rule might as well be run now rather than later; while if on the other hand 
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there is a contradiction, we would like it to be detected as quickly as possible. (This idea, and 
some other ideas about the ordering of the queues, is taken from [Stallman 1977].) 

(3) *van i 11 a-queue*: Ordinary (plain vanilla-flavor) rules. 

(4) *nogood-queue*: Rules with the Qnogood or Qnogoodbeg bit set. Such rules are likely 
to make assumptions, and so arc accorded lower priority than vanilla rules, which are likely to 
be certain of their calculations. 

(5) *defer-queue*: Contradictions which have been deferred until rules have been processed. 
When a contradiction occurs, the user has the option of choosing a premise to retract, or 
requesting that the contradiction processing be “deferred'’ (postponed until rule computations 
have been done) or “punted” (postponed indefinitely). 

The reason for the deferral mechanism is that sometimes it is necessary to make two or more 
changes to the system at once—for example, to alter several parameters. The alterations 
together make the network consistent, but if done sequentially leave the network temporarily 
inconsistent. It may be desirable to postpone contradictions until all the changes have been 
made, whereupon many will be discovered to be “false alarms”. 

(6) * rebel -queue*: Rules some of whose triggers were rebels or dupes at the time of queuing. 
Entries are triples of rule, constraint, and the reason for awakening (needed for re-queuing the 
rule into one of the higher-priority rule queues). 

'The rationale here is that there is no point in computing values from contradictory information. 
When all outstanding contradictions have been processed (from either *contra-queue* 
or *defer-queue*), then there can be no more rebels, and rules are moved from 
♦ rebel- queue* to the other rule queues. 

(7) *punt-queue*: Contradictions which have been postponed indefinitely. The user may be 
asked occasionally whether to process these, but they arc not processed without explicit ap¬ 
proval. (Of course, if they arc not processed then the network may remain in a contradictory 
state.) 


6.2.5. Generalized Algebraic Notation Can Express Any Network 

The use of special notations for the different “points of view” of a constraint arc eliminated. 
Instead of having to represent addition and ” to express its inverse; instead of using “log” 

and the radical sign to express inverses of exponentiation; instead of having to invent silly names 
like “aremax”, we will use a single symbol for each constraint type, and represent inverses by a 
special device. 

A constraint can be notated by writing down the name of its type and what its pins arc con¬ 
nected to. Rather than writing these pieces of information separately, in algebraic notations we 
use a positional convention, which is that the pins are ordered and assigned to positions spatially 
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relative to the position of the name of the constraint type. In fortran, for example, the position 
to the left and right of a “+” are assigned to two pins; writing a variable in such a position means 
that the variables arc connected to the pins; x+y means that x is connected to the first pin of the 
instance of +, and y to the second pin. (Now in FORTRAN the + device can only compute in one 
direction—it is not a constraint—but the use of the word “pins” is meant to be suggestive.) In MSP 
the name is preceded by “(” and successive positions to the right arc connected to successive pins, 
with the last followed by a “)”. In both languages another positional convention holds that the 
expression itself represents one pin; wherever that expression is written, the extra pin is connected 
to the pin for that location. In FORTRAN one writes a*b+c; parsing rules specify that this is 
equivalent to ( a*b )+c. Now the two input pins of * arc connected to two variables a and b, and 
the result pin to the first input of +, because the * expression was written in the position for the 
first input pin of +. (All of these observations appear in [Steele 1979].) 

Here we will allow a constraint to be notated in a manner similar to a MSP expression. 
However, we will not distinguish one pin as the “output” pin, the one to be connected to the 
position where the expression is written. Instead, we have a device to specify which pin serves 
that purpose. We notate a constraint as the name of the constraint-type followed by expressions to 
connect to all the pins. However, one expression can be replaced by the symbol %, which indicates 
that that pin is the one that goes “out the top” to connect to the containing expression’s operator. 

For example, if the pins of the + constraint arc called c, a, and b in that order, then we can 
write y — £ as (+ y % x) or as (+ y x %). In the first case, y is connected to the c pin, x 
to the b pin, and the a pin represents the result. The expression a — arcmax/,(c -f- d/e ) can be 
written as (+ a % (max b % (+ % c (* d % e)))). 

Note that this notational convention makes the order of the pin-names in a defpriin decla¬ 
ration important. 

As a convenient convention, if the first pin in an expression is to be a %, then the % may be 
elided. There fore the expression ( + % x y) may be written as simply ( + x y). This allows 
non-inverse forms of familar algebraic operators to be written in their usual MSP form. 3 


6.2.6. The Size of Nogood Sets Can be I leuristically Reduced 

When a contradiction is discovered, either because some rule of a constraint detected it or 
because two distinct values collided at a node, then contradiction processing locates the premises 

3. Other authors have sometimes done something similar to this. For example, it allows a functional notation for 
relations in predicate logic, and one for example defines /f(S[o], T[b,c\) to be an abbreviation for 3x 3y (S(a,x) A 
T(b, c, y) A ll{r, It))* where /<*, b\ and V are relations. I have purposely allowed elision of the first argument rather 
than the last. Suppose the relation subset (a, b) means that a is a subset of b. If the last argument is elided, then 
subsel(a) means “that x of which a is a subset”, rather than “a subset of which is the meaning if the first 
argument is elided. Similarly, one would like lesslhan(.c) to mean “something less than x", not “something which x 
is less than”. 




§ 6 . 2.6 


The New Improved Techniques 199 


Q 



Figure 6-5. Summarizing Default Cells in the Network. 


of the conflict. These premises collectively form a nogood set, as discussed in §5.2.1. Nogood sets 
can be very large and require a great deal of time to search when checking assumptions. Mere three 
techniques arc outlined for reducing the size of nogood sets, all based on distinctions among valued 
cells. 

The first technique is simply to exclude constant cells from nogood sets. They are now to 
be regarded as a fixed part of the network structure, as permanent as == connections, and never to 
be automatically retracted (indeed, the only way to “retract” a constant now is to disconnect it). In 
the example of the four queens problem in 5.4.2, nogood sets were often formed containing one or 
two assumptions and half a dozen constants that were regarded as fixed. Every time a nogood set 
was checked to see whether it excluded a value, each constant of the set would be checked to ensure 
that it was still constant! Excluding constants from the nogood sets eliminates this overhead. 

The second technique is to order the elements of the nogood set according to the expected 
frequency of change. Parameter cells by definition are assumed to be more variable than default 
cells, so if parameter cells are put at the front of nogood sets where they will be checked first, we 
might expect to be able to terminate check loops more quickly. 

The third technique involves using the network to summarize a collection of default cells 
(which, again, are assumed not to change frequently). Consider the schematic diagram in Figure 6- 
5. The three values V, W, and P2 caused a contradiction at Q. The value V was computed from 
DO, Dl, and D2; W from PO and Y; and so on. The nodes Pj and Dj represent parameters and 
defaults, respectively; CO is a constant, and AO is an assumption. The leaves of the tree arc the 
premises of the contradiction at Q . 
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Now in the previous versions of the constraint system, the leaves would all go into the nogood 
set. By the first technique listed above, we now omit the constant CO from the nogood set.. 
Suppose, however, that we were to put nodes other than premises into nogood sets? This is per¬ 
fectly meaningful. For the situation of Figure 6-5, we might make up a nogood set containing V, W, 
and AO. This would record the fact that the values at those three nodes are contradictory. 1 lowever, 
tliis is not very useful—the constraint combining them at 0 determined that in one step anyway, 
and the purpose of nogood sets is to summarize global, not local, information. Another possible 
nogood set would be V, P0, PI, X, Z, and AO. 

The question is, which nogood sets are useful? In this implementation, nogood sets are 
checked only by rules which produce assumptions (i.e., &nogood and &nogoodbeg rules), and 
by die change statement. 4 Therefore, nogood sets must contain assumptions or cells likely to 
be changed (which by definition are parameters but not defaults) to be useful (this is why in pre¬ 
vious versions process-contradict ion did not record nogood sets unless an assumption was 
involved), and then for speed ought to contain as few other cells as possible. 

There arc many ways a nogood set (or many nogood sets) could be chosen for a contradiction. 
The heuristic method used here is that if any cell in the dependency tree is supported only by 
default cells (and constant cells, but they don’t count anyway), then that cell may be used in the 
nogood set in lieu of the default cells, provided there are more than one (that is, the summarization 
is used only if it strictly decreases the size of the nogood set). Assumptions and parameter cells 
must be explicitly included in nogood sets. Thus for Figure 6-5 the nogood set actually chosen 
would be V (summarizing DO, Dl,and D2), P0, PI, Y (summarizing D3and D4), and 05 (which 
could be summarized by Z but is not because it wouldn’t decrease the size of the nogood set). 


6.2.7. Statistics Counters Measure Performance 

This version of the constraint system is instrumented with a system of statistics counters (a 
generally useful package of i.isp functions in its own right). This will allow us to count such events 
as number of rules queued, number of cells generated, and so on. 


4. In principle, any computed result could be checked against existing nogood sets in process-setc, and perhaps 
this would be a good thing; but I deemed this an unnecessary complication with unclear benefits. 
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;;; Values of the STATE component of a CELL. 

(defconst ©king (list '@king)) ;has value, is supplier 

(defconst ©puppet (list '©puppet)) ;no value, is supplier 

(defconst ©friend (list '©friend)) ;has value, believes supplier 

(defconst @slave (list '©slave)) ;no value, believes supplier 

(defconst ©rebel (list '©rebel)) ;has value, opposes supplier 

(defconst @dupe (list '©dupe)) ;no value, believes a rebel 

;;; Bits which can be set in the RULE-BITS component of a RULE. 

(defconst ©rule-nogood 1) 

(defconst ©rule-nogoodbeg 2) 

;;; Values returned by the CODE function of a RULE. 

(defconst @lose (list '©lose)) ;contradict ion detected 

(defconst ©dismiss (list '©dismiss)) ;no value computed 

;;; Special flags returned by CTIOOSE-CULPRIT. 

(defconst ©defer (list '©defer)) ;contradiction should be deferred 

(defconst ©punt (list '©punt)) ;contradict ion should be punted 

;;; Reasons for enqueuing a RULE. 

(defconst ©added (list '©added)) ;a trigger received a new value 

(defconst ©forget (list '©forget)) ;the outvar is begging for a value 

(defconst ©nogood (list '©nogood)) ;a nogood for the outvar was flushed 

;;; Reasons for contradictions in entries of *CONTRA-QUEUE* and friends, 
(defconst ©node (list '©node)) ;the node contains a rebel 

(defconst ©constraint (list '©constraint)) ;a constraint rule detected it 

(defconst ©resolution (list '©resolution)) ;resolution on nogood sets 

Tabu: 6-1. Definitions of Symbolic Constants. 


6.3. The New Improved Implementation 

In this section the entire source code for the new systein is presented, complete in itself. 


6.3.1. Symbolic Constants Provide Names for Internal Marker Values 

Symbols declared by the defconst construct arc symbolic constants. They are implemented 
as global lisp variables, but their values arc supposed not to change. As a matter of programming 
convention, symbolic constants of the constraint system have names beginning with Some 
of the constants are special numeric values, but most arc just LISP objects whose nature doesn’t 
particularly matter as long as they arc recognizably distinct from all other objects. For this purpose 
a freshly conscd list of the name of the constant is used. This makes the constant recognizable 
when it is printed; the fresh consing ensures uniqueness. Definitions of symbolic constants used 
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in the constraint system appear in Table 6-1. The names @king, Spuppet, @f riend, @sl ave, 
Srebel, and @dupe are used to mark the state of a cell, for instance. These constants are thus 
effectively the elements of PASCAl.-stylc enumerated data types. 
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(defvar *al1-statistics-counters* '()) 

(defmacro statistics-counter (name description) 

(let ((varname (symbolconc "*" name "-STATISTICS-COUNTER*"))) 

‘(progn 'compile 

(or (assq varname *all-statist ics-counters*) 

(push '(,varname description) *al1-statistics-counters*)) 
(defvar ,varname 0)))) 

(defmacro statistic (name) 

‘ (increment ,(symbolconc "*" name "-STATISTICS-COUNTER*"))) 

(defun stats () 

(dolist (x (reverse *al1-statistics-counters*)) 

(format t "~%;~7D = ~A" (symeval (car x)) (cadr x)))) 

(defun reset-stats () 

(dolist (x *al1 -statistics-counters*) (set (car x) 0))) 

Tabu- 6-2. Statistics Counter Mechanism. 


6.3.2. Statistics Counters Make It Easy to Instrument Code 

Table 6-2 defines a simple statistics-gathering mechanism. The declaration 
(statistics-counter foo "Globbitzes frobbotzed while nurbling the scrol") 

creates a statistics counter named foo. The string is a description of the meaning of the counter. 
This has the effect of defining a global variable named *f oo-stat i st i cs-counter*, initializ¬ 
ing it to zero, and adding it to a list of all declared statistics counters. One can insert into a piece of 
code the statement 

(statistic foo) 

which will cause the count in counter foo to be incremented. The function stats will print all 
the statistics, one per line, in the format: 

; 2960 = Globbitzes frobbotzed while nurbling the scrol 

; 45613 = Queued rules with no output pin 


The function reset-stats resets all the counters to zero. 

In the code to follow there will be many call on the statistic macro. Tike calls to 
ct race and requ i re - type , they can be ignored for purposes of understanding the computation. 
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(deftype constraint-type 

(ctype-naine ctype-vars ctype-added-rules ctype-forget-rules 
ctype-nogood-rules ctype-symbol) 

(format stream ”<Constraint-type ' J S>" {ctype-name constraint-type))} 

(deftype constraint (con-name con-ctype con-values con-info (con-queued-rules 0)) 
(format stream ”<~S:~S>’’ 

(con-name constraint) (ctype-name (con-ctype constraint)))) 

(deftype rule ((rule-triggers '()) (rule-outvar ()) rule-code 
(rule-bits 0) (rule-ctype ()) rule-id-bit) 

(format stream 

": [~4*~ ; ~ : [(~S~@[~* &NOGOOD~]~@[~* &N0G00DBEG~] )«-~ ]~]~ 

~S(~{~S~f)>" 

(rule-outvar rule) 

(zerop (rule-bits rule)) 

(and (rule-ctype rule) 

(rule-outvar rule) 

(aref (ctype-vars (rule-ctype rule)) (rule-outvar rule))) 

(bit-test @rule-nogood (rule-bits rule)) 

(bit-test @rule-nogoodbeg (rule-bits rule)) 

(rule-code rule) 

(and (rule-ctype rule) 

(forlist (tr (rule-triggers rule)) 

(aref (ctype-vars (rule-ctype rule)) tr))))) 

Tabu; 6-3. Data Structures for Constraint-types, Constraints, and Rules. 


6.3.3. Rules Are Data Structures and Catalogued in Arrays 

Tabic 6-3 shows the definitions of the data structures described in §6.2.2. An additional feature 
of interest is the new printing formats for constraints and rules. A constraint is now uniquely 
named by a global variables, and so its id is not printed. Instead it just prints as the name and its 
type: 

(create foo adder) 

<F00:ADDER> 

The format for printing rules is intended to show the functional dependence of the rule by 
using die outvar and trigger information. The five rules for gate which were defined in §6.2.2 
print in this way: 

<A*-GATE-RULE-15( P,B)> 

<B<-GATE-RULE-16(P,A)> 

<P*-GATE-RULE-17( A,B)> 

<(P &I\I0G00DBEG)*-GATE-RULE-18( )> 

<GATE-RULE-19(P)> 
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Rules 15, 16, and 17 are vanilla-flavor rules; rule 18 has the Snogoodbeg bit set and has no 
triggers; and rule 19 has no output pin, and so is a detector rule. 
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(deftype repository ((rep-cells ()) (rep-supplier ()) rep-id 

(rep-nogoods '()) (rep-contra 0)) 

(format stream "<Repository~@[ for ~{~S~t 
(cell-ids repository))) 

(defmacro node-cells (cell) ‘(rep-cells (cell-repository ,cell))) 

(defmacro node-supplier (cell) ‘(rep-supplier (cel 1-repository ,cell))) 
(defmacro node-mark (cell) ‘(cell-mark (node-supplier ,ce 11))) 

(defmacro node-nogoods (cell) ‘(rep-nogoods (cell - repository ,cell))) 

(defmacro node-contra (cell) ‘(rep-contra (cel 1-repository ,cell))) 

(deftype cell (cell-id cell-repository cell-owner cell-name 

(cel 1-contents ()) (cell-state ©lose) (cell-rule ()) 

(cell-equivs '()) (cell-link ()) (cell-mark ())) 

(progn (format stream "<~S (~S~@[ of ~S"])" 

(cel 1-id cel 1) 

(if (cel 1-owner cel 1) 

(aref (ctype-vars (con-ctype (cell-owner cell))) 

(cell-name cell)) 

(cell-name cell)) 

(and (cell-owner cell) (con-name (cell-owner cell)))) 

(select (cell-state cell) 

((©puppet) (format stream " PUPPET>")) 

((©slave) (format stream " SLAVE~@[ ~S~]>" 

(select (cell-state (node-supplier cell)) 

((©king) (node-value cell)) 

((©puppet) ()) 

(otherwise 

(list 'bad-supplier 

(cell-state (node-supplier cell))))))) 
((©king) (format stream "~@[~* [OPPOSED]~] KING ~S>" 

(plusp (node-contra cell)) 

(ce 11-value cell))) 

((©friend) (format stream "~@[~* [OPPOSED]~] FRIEND ~S>" 

(plusp (node-contra cell)) 

(cell -value cel 1))) 

((©rebel) (format stream " REBEL ~S AGAINST ~S>" 

(cel 1-value cel 1) 

(if (eq (cell-state (node-supplier cell)) ©king) 

(node-value cel 1) 

(list 'bad-supplier 

(cell-state (node-supplier cell)))))) 
((©dupe) (format stream " DUPE ~S AGAINST ~S>" 

(cel 1-value cell) 

(if (eq (cell-state (node-supplier cell)) ©king) 
(node-value cell) 

(list 'bad-supplier 

(cell-state (node-supplier cell)))))) 
(otherwise (format stream " BAD STATE ~S>" (cell-state cell)))))) 

(defun cell-ids (rep) 

(require-repository rep) 

(foriist (x (rep-cells rep)) (cell-id x))) 

Table 6-4. Data Structures for Repositories and Cells. 
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6.3.4. Cells 1 lave Fields That Were Formerly in Repositories 

The definitions for the new repository and cell data structures described in §6.2.1 are shown 
in Tabic 6-4. As before, macros named node-cells, node-supplier, node-nogoods, and 
node-contra are provided for accessing fields of a repository given a cell. Sometimes a graph- 
macking algorithm wants to mark a node and not just an individual cell, but we have moved the 
mark component from repositories to cells; the solution is to define node-mark to access the 
mark component of the node’s supplier. (This is only one reason why a node always has a supplier.) 

The printing format for cells has been updated to be more informative. Consider for example 
this interaction. After these statements: 

(create foo gate) 

<F00:GATE> 

(progn (variable x) 

( = = x (the p foo)) 

(== (the a foo) (parameter 5)) 

(== (the b foo) (parameter 5)) 

(variable y) 

(= = y (default 6)) 

(== y (the b foo))) 

(yes, progn is not part of the language, but 1 cheated for conciseness), foo is a gate; its p is 
connected to x; its a has the parametric value 5; and its b has the parametric value 5 and is also 
connected to y which had the default value 6. This causes a contradiction of course, within which 
we can examine the cells: 

;;; These are the premises that seem to be at fault: 

CCELL-78 (DEFAULT-76) REBEL 6 AGAINST 5> == Y, 

; <CELL-72 (PARAMETER-70) [OPPOSED] KING 5> == Y. 

;;; Choose one of these to retract and RETURN it. 
x 

<CELL-61 (X) SLAVE> 

(the p foo) 

<CELL-55 (P of FOO) PUPPET> 

(the a foo) 

<CELL.-57 (A of FOO) SLAVE 5> 

(the b foo) 

<CELL-59 (B of FOO) SLAVE 5> 

y 

<CELL-75 (Y) DUPE 6 AGAINST 5> 

(node-supplier (the b foo)) 

CCELL-72 (PARAMETER-70) [OPPOSED] KING 5> 

(cel 1-contents y) 
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<CELL-78 (DEFAULT-76) REBEL 6 AGAINST 5> 

(Note the use in the lisp code of the special form select, which is like the case statement 
of algebraic languages. Note too that an otherwise clause has been provided, to print cells 
which somehow have a bad state component. Similarly, the code is tolerant of a supplier other than 
a king or puppet (this can occur when printing a trace message). The printer is a debugging tool, 
and debugging tools must be fairly robust, tolerating errors in the data structures!) 
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(defun node-boundp (cell) 

(require-cell cell) 

(select (cell-state (node-supplier cell)) 

((©king) t) 

((@puppet) ()) 

(otherwise (lose "The supplier ~S has a bad state." (node-supplier cell))))) 

(defun node-value (cell) 

(require-cell cell) 

(let ((s (node-supplier cell))) 

(or (eq (cell-state s) @king) 

(lose "Supplier ~S for cell ~S isn't a ©KING." s cell)) 

(cel 1-contents s))) 

(defun cell-value (cell) 

(require-cell cell) 

(select! (cell-state cell) 

((©slave) (node-value cell)) 

((©king ©friend ©rebel) (ce 11-contents cell)) 

((©puppet) (lose "Can't take value of the ©PUPPET ~S." cell)) 

((©dupe) 

(let ((c (cel 1-contents cell))) 

(require-cell c) 

(or (and (eq (cel 1-repository cell) (cel 1-repos i tory c)) 

(eq (cell-state c) ©rebel)) 

(lose "Bad ©DUPE indirection from ~S to ~S." cell c)) 

(cell-contents c))))) 

(defun node rule (cell) 

(require-cel 1 cell) 

(let ((s (node-supplier cell))) 

(or (eq (cell-state s) ©king) 

(lose "Supplier ~S for cell ~S isn't a ©KING." s cell)) 

(cel 1-rule s))) 

(defun cel 1-true-supplier (cell) 

(require-cel 1 cell) 

(select! (cell-state cell) 

((©king ©rebel ©friend ©puppet) cell) 

((©slave) (node-supplier cell)) 

((©dupe) (ce 11-contents cell)))) 

Table: 6-5. Funelions for Accessing Values of Cells and Nodes. 
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6.3.5. The Value of a Cell May Differ from the Value of Its Node 

Because the node data structure can now tolerate contradictions in the form of rebel cells, the 
value of a cell is not necessarily that of the node’s supplier. Table 6-5 provides some functions 
which are useful for manipulating values of cells and nodes. Those whose names begin with 
node- deal with the supplier of the given cell’s node; those whose names begin with cel 1 - deal 
with the given cell itself. 

The function node-boundp is a predicate true iff the node has a value; it checks the sup¬ 
plier (and in the process ensures that it is a king or puppet). (It is not necessary to have a separate 
function cel 1 -boundp. If a cell is a king or puppet, then it is the supplier, and so is bound iff the 
node is. If it is a friend, rebel, or dupe, then it is bound: but then there must be a king, and again 
is the cell bound iff the node is. Finally, a slave by definition has a value iff the node (the supplier) 
does.) 

If the node has a value, then node-value will fetch the value (the contents component of 
the suplicr cell, which must be a king). Similarly, cel 1 - value will get the value of the given cell, 
which is the cell’s own value if it is a king, friend, or rebel; the supplier’s value, for a slave; or the 
believed-in rebel’s value, for a dupe. (A puppet can never have a value.) The function node - rul e 
gets the rule used to compute the node’s value. (The function (actually macro) cel 1 - rule ob¬ 
viously accesses the cell's rule component, as specified in the definition of the data type cell. The 
concept of fetching the rule that computed the cell’s value is reasonable, and also ought to be called 
ce 11 - ru 1 e by these conventions, but it turned out not to be needed, and so the naming difficulty 
was avoided. One can instead take the cell-rule of the cell-true-suppl ier ofthe cell.) 

(Ihc LISP special form select! is similar to select but automatically supplies an 
otherwise clause which signals a correctable LISP error if no other clause is selected. In contrast, 
select merely returns () if no clause is selected, by analogy with cond. Using select! 
makes debugging easier without having to provide explicit error checking whenever a selection 
statement is written.) 

The function cel 1 - true-suppl ier returns the supplier which the given cell “believes”. 
Kings, rebels, friends, and puppets believe in themselves (puppets have no values, but they are still 
suppliers); slaves believe in the node’s supplier; and dupes believe in some rebel they point to. 
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(statistics-counter yen - repository "Repositories generated") 


(defun gen-repository () 

(statistic gen-repository) 

(let ((r (make-repository)) 

(n (gen-name 'rep))) 

(setf (rep- id r) n) 

(set n r) 
r )) 

(defun node-lessp (x y) 

(require-cell x) 

(require-cel 1 y) 

(alphalessp (rep-id (cel 1-repository x)) (rep-id (cell-repos itory y)))) 

(statistics-counter gen-cell "Cells generated") 

(defun gen-cell (name &optional (owner () ownerp)) 

(and ownerp (require-constraint owner)) 

(if ownerp (require-integer name) (require-symbo1 name)) 

(statistic gen-cel 1) 

(let ((c (make-cell)) 

(r (gen-repository)) 

(n (gen-name 'cell))) 

(setf (cell id c) n) 

(set n c) 

(setf (cell-owner c) owner) 

(setf (cell-name c) name) 

(setf (cell-repository c) r) 

(push c (rep-cel 1s r)) 

(setf (cell-state c) ©puppet) 

(setf (rep-supplier r) c) 

c)) 


Tabi.k()- 6. Generation of Repositories and Cells. 


6.3.6. A Newly Generated Cell is Its Own Puppet 

The code for generating new repositories and cells in in Table 6-6. Note the two statistics 
counters for counting the number of repositories and cells generated. 

If a new cell has no owner, then its name must be a symbol; but if it has an owner, its name 
must be an integer (a pin number). The initial stale of any new cell is Spuppet, and it becomes 
the supplier of its one-cell node. 
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(deftype hashtable ((hash tab I e-populat ion 0) hash tab! e-array 

(hashtable-probes 0) (hashtable-lookups 0) 
hashtable-key-extractor hashtable-load-factor-1imit) 

(format stream "CHashtable ~S size=~D populalion^D load factor=~S avg probes=~S>" 
(li ash table-key-extractor hashtable) 

(array-length (hashtable-array hashtable)) 

(hashtable-popnlat ion hashtable) 

(// (float ( hasht.able-populat ion hashtable)) 

(array-1 engLh (hashtable-array hashtable))) 

(if (zerop (hashtable-lookups hashtable)) '? 

(+ (// (float (hashtable-probes hashtable)) 

(hashtable-lookups hashtable)) 

1 )))) 

(defun gen-hashtable (kex &optional (size 63.) ( 1 oad-factor-1imit 0.75)) 

(let ((h (make-hashtable))) 

(setf (hashtable-array h) (array-n ( (t 2 (haulong size)) 1))) 

(setf (hashtable-key-extractor h) kex) 

(setf (hashtable-load-factor-1 imit h) load factor-1imit) 

h)) 


Tabu- 6-7. Hash Tabic Definition and Generation. 


6.3.7. I lash Tables Store and Retrieve Objects Indexed by Given Keys 

We will have an application for hash tables in a moment, and so we pause here to define an 
implementation. This section is not a general treatise on hashing, and the code presented here is 
not even a particularly good (or particularly bad) hashing technique. Cor a more general treatment, 
see [Knuth 1973]. Table 6-7 shows the definition for the data type hashtable, which has these 
components: 

(a) array, an array used to store hashed records. A record may be any object other than (), which 
is used to indicate an unused array position. 

(b) key-extractor, which is a function which when given a record will extract the record’s key, 
which must be an integer. (While keys must be integers, they may be very large integers, and so 
simply using the key itself as the array index is not a practical technique.) 

(c) population , the number of occupied positions in the array. This is present purely for speed; it 
could he computed by scanning the array. 

(d) load-factor-limit. The load factor of the hash array is (he population divided by the total array 
size, i.e., the percentage of used positions. The load-J'actor-limit is a limit on this percentage; 
when the population becomes too large, then the array must be expanded. (Analyses such 
as those in [Knuth 1973] indicate that the expected time to access a hash array is roughly a 
function of the load factor. Hence keeping the load factor low will improve the access time.) 
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(defun hash-lookup (n hashtable) 

(prog ret () 

(increment (hash tab 1e-1ookups hashtable)) 

(let ((a (hashtable-array hashtable)) 

(kex (hashtable-key-extractor hashtable))) 

(let ((s (array-length a))) 

(do ((probe (mod n s) (mod (+ probe 1) s))) 

((null (aref a probe)) 

(return-from ret () probe)) 

(increment (hash tab 1 e-probes hashtable)) 

(and (equal (funcall kex (aref a probe)) n) 

(return-from ret (aref a probe) probe))))))) 

(defun hash-install (k obj hashtable) 

(let ((a (hashtab1 e-array hashtable)) 

(kex (hashtable-key-extractor hashtable))) 

(or (null (aref a k)) (lose "~D slot already filled in ~S." k hashtable)) 
(aset obj a k) 

(increment (hashtable-population hashtable)) 

(let ((s (array-length a))) 

(and (> (hashtable-population hashtable) 

(* s (hashtable-1oad-factor-lim i t hashtable))) 

(let ((newarray (array-n (+ (* s 2) t)))) 

(setf (hash tab I e-array hashtable) newarray) 

(dotimes (j s) 

(or (null (aref a j )) 

(multiple-value-bind (item slot) 

(hash-lookup (funcall kex (aref a j)) hashtable) 

(and item (lose "Weird hashtable bug: item ~S in ~S." 
item hashtable)) 

(aset (aref a j) newarray slot))))))) 

obj)) 

Tablh 6-8. Hash Table Lookup and Install Operations. 


(e) lookups , the number of times the hashtable has been accessed. This is a statistics counter, blit is 
not done via the standard statistics counter mechanism so that it will be per-hashtablc. 

(f) probes , another statistics counter, measuring die number of unsuccessful accesses to the array. 
This plus lookups , all divided by lookups , is the average number of accesses per lookup (a 
quantity one seeks to minimize in the interests of speed). 

'The function gen-hash tabl e takes a key-extractor function and creates a hashtable 
around it. The initial size defaults to 63, and the load factor to 0.75. The size is constrained to 
be one less than a power of two. (The LISP function haul ong, applied to an integer x, computes 
flog'iCM + 1)1 (d > s the “length of x in bits”); thus 

2 haulong(a:)_^ 

is some n which is one less than a power of two and not less than x. This is a not unreasonable 
length for a hashtable, using key (mod n) as the hashing function. The function array-n takes 
an integer and constructs a zero-origin array of that length.) 
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The function hash-lookup (Table 6-8) takes a key and a hashtable and tries to find a 
record with that key in the table. It returns two values. The first is the record if one was found, or 
() if none was found. The second is the index into the hash array where the record was found or 
the search terminated. (This returning of two values is done via the Lisp Machine LISP multiple- 
value mechanism. If several arguments arc given to the return function or one of its variants, 
then all the arguments arc collectively returned from the enclosing prog. If the prog’s function 
was invoked via a normal function call, then the first value returned is the functional value, and the 
rest arc discarded. However, special forms such as mul t iple-val ue-b i nd can be used to get 
the other values. This technique avoids consing up and picking apart a list of results; internally all 
the returned values are passed “on the stack”.) 

The function hash-install takes an index supplied by hash-lookup, a record (which 
should have as key diat key used to obtain the index), and a hashtable. It installs the record in 
die table, and if the load factor has exceeded the limit it creates a new hash array, installs it in the 
hastablc data structure, and copies the contents of the old array into the new one by re-hashing 
diem. 
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(progn 'compile 

(defglobal *constant-rule* (make-rule)) 

(setf (rule-code *constant-rule*) 'constant-code) 

(defun constant-code (*me*) (lose "Constant rule invoked on ~S." *me*))) 
(progn 'compile 

(defglobal *defaul t-rule* (make-rule)) 

(setf (rule-code *defau1t-rule*) 'default-code) 

(defun default-code (*me*) (lose "Default rule invoked on ~S." *me*))) 
(progn 'compile 

(defglobal *parameter-rule* (make-rule)) 

(setf (rule-code *parameter-rule*) 'parameter-code) 

(defun parameter-code (*me*) (lose "Parameter rule invoked on ~S." *me*))) 

(defun globalp (cell) 

(require-cel 1 cell) 

(and (null (cell-owner cell)) (null (cell-rule cell)))) 

Tam 1-6-9. Dummy Rules for Constant, Default, and Parameter Cells. 


6.3.8. Constant, Default, and Parameter Cells Have Dummy Rules 

Valued cells (those created by the constant, default, and parameter constructs) are 
distinguished by the presence of distinguished dummy rules, which are the values of the variables 
♦constant-rule*, *defaul t-rule*, and *parameter-rule*, defined in Table 6-9. For 
uniformity, every cell which has its own value (whether a valued cell or a pin) must have a title. 
However, it is an error ever to invoke the rule of a valued cell. To guard against this possibility (as 
a matter of defensive programming), these dummy rules are provided wioth code components that 
will signal a meaningful error. 

Cells for global variables, on the other hand, never have values of their own; they can be 
distinguished by this fact. Hence the predicate globalp, true iff its argument (a cell) is a global 
cell, merely checks that the cell has no owner and no rule. 

The function i n i t i al i zed-cel 1 creates a valued cell of specified type (here specified by 
which dummy rule is provided). A valued cell is initially its own king. Default and parameter cells 
arc generated in similar ways; a name is generated, an initialized cell of that name generated with 
the appropriate dummy rule, the name given the cell as its value, and the cell returned. 

For constants, however, a hash tabic is used. The global lisp variable *constants* is a 
hashtablc used for hashing all constant cells. The function constant-va 1 ue serves as the key- 
extractor. To generate a constant of given value, the value is used as the lookup key for the hash¬ 
tablc (note the use of multiple-value-bind to get both the cell, if any, and the hash index). 
If a cell with that value is already in the table, it is returned; thus constants are “shared” among 
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(statistics-counter init-cell "Initialized cells") 

(defun initialized-cel1 (value name rule) 

(require-integer value) 

(let ((cell (gen-cell name))) 

(setf (cel 1-contents cell) value) 

(setf (cell-rule cell) rule) 

(setf (cell-state cell) @king) 
cell)) 

(defun default (value) 

(let ((name (gen-name 'default))) 

(let ((cell (initialized-cel1 value name *default-rule*))) 

(set name cell) 
cell))) 

(defun parameter (value) 

(let ((name (gen-name 'parameter))) 

(let ((cell (initialized-cel1 value name *parameter-rule*))) 

(set name cell) 
cell))) 

(defun constant-value (cell) (cel 1 contents cell)) 

(defglobal ^constants* (gen-hashtable 'constant-value)) 

(defun constant (value) 

(require-integer value) 

(multiple-value-bind (item slot) (hash-lookup value ^constants*) 

(or item (hash-install slot 

(initialized-cel! value 'constant *constant-rule*) 
*cons tants*)))) 

Table 6-10. Generation of Constant. Default, and Parameter Cells. 


requests. Otherwise a new constant cell is created and installed in the hashtablc. (The definition of 
hashtablcs in §6.3.7 was a little long, but see now how concisely one can be used! This is the mark 
of a useful data abstraction.) 

The sharing of constant cells is not without peril. We must ensure that a constant cell, once 
created, is immutable, and particular can never be retracted. Later we will sec code that checks for 
this explicitly. 
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(defmacro variable (name) ‘(progn (^destroy ',name) (setq ,name (gen-cell ',name)))) 

(defmacro create (name type) i (*create ',name ,type)) 

(defun ^create (name type) 

(prog2 (*destroy name) 

(gen-constraint type name) 

(run?))) 

(statistics-counter gen-constraint "Constraints generated") 

(defun gen-constraint (ctype name) 

(require-constraint-type ctype) 

(statistic gen-constraint) 

(require-symbol name) 

(let ((c (make-constraint))) 

(set name c) 

(setf (con-name c) name) 

(setf (con-ctype c) ctype) 

(setf (con-values c) 

(array-of (fortimes (j (array-length (ctype-vars ctype))) 

(gen-cell j c)))) 

(doarray (bucket (ctype-forget-rules ctype)) 

(do Iist (rule bucket) 

(and (null (rule triggers rule)) 

(enqueue-rule rule c @forget)))) 

c)) 


Tabu: 6-11. Declaration of Variables and Constraints. 


6.3.9. Declaration of Variables and Constraints May Require Housekeeping 

The variable and create constructs arc implemented as I ISP macros in Table 6-11. A 
feature common to both is that before proceeding the the definition the function ^destroy is 
called. We will see the definition of this much later; suffice it for now to note that it implements 
the destroy operation, causing any old value of the variable to be explicitly garbage-collected. 
The reason for this care is that the versions of the constraint system in the previous chapter were 
subject to a subtle (but fortunately seldom encountered) difficulty: if one were to declare a variable 
or constraint, then re-dcclarc it, the old and new declarations might co-exist in a single network, 
causing some confusion. For example, tine sequence of statements 

(variable x) 

(create foo adder) 

(== x (the a foo)) 

(create foo adder) 

(== x (the a foo)) 
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would cause the variable x to be connected to the a pins of two adders, the old foo and the 
new foo! Explicit destruction of the old value avoids this. Destroying a variable or constraint first 
disconnects it from everything else. 

When a constraint is generated, the initialization is a little more complicated than before. An 
array of pin cells must be created for the values component. (The lisp function array-of takes a 
list and creates a zero-origin array with the same length as the list, and initializes the array elements 
from the list in order.) 

When the constraint has been generated, there is one final task. There may be rules of the 
constraint-type which have output pins and no triggers (probably, but not necessarily, they are 
@nogood or ©nogoodbeg rules which produce a value speculatively). These rules must be 
awakened immediately, to beg for a value, because all their triggers arc satisfied! This is done by 
the doubly nested loop at the end of gen-constraint. The awakening is done by enqueuing 
the relevant rules. 

An important principle is that queued rules must be given a chance to run. Therefore, when¬ 
ever there is a possibility that a rule (or, for that matter, a contradiction or any other task (though 
there arc no other kinds in this implementation, 1 strive for generality!)) has been queued, the func¬ 
tion run? must be called. This function has the responsibility for starting up the task scheduler if 
appropriate. Nearly all the functions which implement user statements of the constraint language 
end by calling the run? function; *c reate is one example. 
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(deftype queue (queue-name (queue-entries '()) (queue-count 0)) 

(format stream "<~S ~D entr~:@P ~D enqueuing":P>" 

(queue-name queue) (length (queue-entries queue)) (queue-count queue))) 

(defglobal *a11-queues* '()) 

(defun queue-stats () 

(dolist (q (reverse *all-queues*)) (print q))) 

(defun reset-queues () 

(dolist (q *al1-queues*) 

(setf (queue-entries q) ()) 

(setf (queue-count q) 0))) 

(defmacro defqueue (name) 

‘(progn 'compile 

(declare (special ,name)) 

(setq ,name (make-queue)) 

(setf (queue-name ,name) ',name) 

(push ,name *al1-queues*) 

',name)) 

Tabu- 6-12. Queue Data Structure and Definition. 


6.3.10. A Queue Is Yet Another Abstract Data Structure 

A queue is implemented as a data structure with a name, a list of entries, and a statistics 
counter. (As with hashtables, queue statistics are maintained on a per-queue basis. The counter 
counts the number of entries ever enqueued on the queue. This minus (lie length of the list of 
entries yields the number of entries ever dequeued.) The global ijsp variable *al 1-queues* 
accumulates a list of all queues ever defined, and the function queue-stats prints the queue 
statistics (simply by printing the queues, inasmuch as the print function for queues prints the 
relevant statistics anyway). 

The function reset-queues causes all queues to be reset; their entries are forcibly 
removed, and their counters reset to zero. This is a useful debugging tool when a computation 
blows up in the middle. 

flic macro def queue defines a queue of a given name. It make a queue data structure, 
associates the name with it, and adds the queue to the list of all queues. 

'flic operations on queues arc defined in 'fable 6-13. flic predicate queuep is true iff the 
argument queue has any entries; it is not legal to dequeue an entry unless this predicate is true. 
(This is not to be confused with queue-p, defined by the deftype declaration of the queue data 
type, which is a predicate true iff its argument is a queue!) 
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(defmacro queuep (queue) ‘(not (null (queue-entries ,queue)))) 

(defglobal *queue-trace* t) 

(defun enqueue (item queue) 

(require-queue queue) 

(and *queue-trace* 

(ctrace "Enqueuing ~S onto ~S." item (queue-name queue))) 

(increment (queue-count queue)) 

(push item (queue-entries queue))) 

(defun dequeue (queue) 

(require-queue queue) 

(and *queue-trace* 

(ctrace "Dequeuing ~S from ~S." 

(car (queue-entries queue)) 

(queue-name queue))) 

(pop (queue-entries queue))) 

(defun movequeue (to from) 

(require-queue to) 

(require-queue from) 

(and *queue~trace* 

(ctrace "Moving ~S to ~S." from to)) 

(setf (queue-count to) (+ (queue-count to) (length (queue-entries from)))) 
(setf (queue-entries to) (append (queue-entries from) (queue-entries to))) 
(setf (queue-entries from) '())) 

(defmacro fromqueue ((var queue) . body) 

‘(let ((,var ())) 

(unwind-protect (prog2 (setq ,var (dequeue ,queue)) 

(progn ,@body) 

(setq ,var ())) 

(and ,var (enqueue ,var ,queue))))) 

Tablf. 6-13. Queue Operations. 


The enqueuing and dequeuing operations provide ctrace output. However, because queue 
operations arc so numerous, the trace output from queuing operations can swamp all other trace 
output. Therefore, a special switch *queue-trace* is provided to suppress tracing of queue 
operations while permitting other trace output. 

The function enqueue adds an entry to a queue (incrementing the statistics counter for the 
queue); the function dequeue removes an entry and returns it. This particular implementation 
happens to provide LIFO (last-in, first-out) queues. This was done for no particular reason other 
than that it was easy. A useful experiment would be to compare different queuing methods for 
efficiency in running constraint systems. 

The operation movequeue moves all the entries from one queue to another in one fell 
swoop; it is more efficient than separately dequeuing and enqueuing each entry. The statistics 
counter of the to-queue is incremented by the number of entries moved. 
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The macro fromqueue is provided for dequeuing and processing queue entries in a 
protected manner. The form 

(fromqueue ( var queue) ... body ... ) 

expands into 

(let (( var ())) 

(unwind-protect (prog2 (setq var (dequeue queue)) 

(progn ... body ... ) 

(setq var ())) 

(and var (enqueue var queue )))) 

Now the LISP special form unwind-protect guarantees to execute all argument forms but the 
first when returning from evaluation of the first. Bvcn if there is some kind of error, or throw 
operation, the extra argument forms arc evaluated as the stack is unwound (hence the name) past 
that point. The fromqueue macro binds the specified variable, then dequeues a queue entry from 
the queue and assigns it to var. Things are a trifle unsafe during the instant between the dequeue 
and the se tq —an asynchronous interrupt at that point could mess things up—but all is well once 
dif irst setq has taken place. If for any reason an error occurs during processing of the body, 
then the entry will be re-queued. (An important case of this is that when processing a contradiction 
control may be given to the user to choose a culprit. He might well just quit to the LISP top level— 
in which case the contradiction queue entry must not be lost.) Only if processing is successfully 
completed and var set to () is the re-enqueuing avoided. (The safety factor is die entire reason for 
the f romqueue macro. That is why the simpler expansion 

(let ((var (dequeue queue))) 

(unwind-protect (progl (progn ... body ... ) 

(setq var ())) 

(and var (enqueue var queue)))) 

is not used. The period of unsafety from asynchronous interrupts would extend over the setting up 
of the unwi nd-protect mechanism.) 
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;;; Definitions of queues, 
(defqueue *contra-queue*) 
(defqueue *detector-queue* 
(defqueue *vanil1a-queue* ) 
(defqueue *nogood-queue*) 
(defqueue *defer-queue*) 
(defqueue *rebel-queue*) 
(defqueue *punt-queue*) 


in priority order 

;contradictions to be processed 
;ruies with no outvars 
;piain rules 

;&N0G00f) and &N0G00DBEG rules 
•.contradictions deferred until rules processed 
•.rules which depended on contradictory values 
;contradictions deferred indefinitely 


(defglobal *run-flag* t) 
(defglobal *rebel-f1ag* ()) 


(defun run? () (and *run-flag* (run!))) 


(statistics-counter run "Iterations of top-level-loop queue scan") 


(defun run! () 

(do () (()) ;forever 

(statistic run) 

(cond ((queuep *contra-queue*) 

(fromqueue (item *contra-queue*) (run-contra item))) 

((queuep *detector-queue*) 

(fromqueue (item *detec tor-queue*) (run-rule item))) 

((queuep *vanilla-queue*) 

(fromqueue (item *vani11a-queue*) (run-rule item))) 

((queuep *nogood-queue*) 

(fromqueue (item *nogood-queue*) (run-rule item))) 

((queuep *defer-queue*) 

(movequeue *contra-queue* *defer-queue*)) 

((and (null *rebel-flag*) (queuep *rebe1-queue*)) 

(setq *rebel-flag* t) 

(do () 

((not (queuep *rebel-queue*))) 

(let ((item (dequeue *rebel-queue*))) 

(enqueue-rule (car item) (cadr item) (caddr item))))) 

((and (queuep *punt-queue*) (y-or-n-p "Process punted contradictions?")) 

(movequeue *contra-queue* *punt-queue*)) 

(t (return 'done))))) 


Tablh6-14. Constraint System Queue Definitions and Task Scheduler. 
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6.3.11. The Task Scheduler Simply Scans the Queues in Order 

Tabic 6-14 declares the queues used in this implementation of the constraint system (which 
were described in §6.2.4). The priority order of the queues has nothing to do with the order of dec¬ 
laration (though they arc in fact declared in order for readability): the priority order is determined 
by the task scheduler, the function run!. To provide a handle on the scheduler for debugging 
purposes (for example, to examine the shite of the queues after entries have been queued and 
before they arc processed), there is a switch *run-f 1 ag *. flic function run? calls run ! only if 
* run-flag* is set (which it normally is). 

The task scheduler checks the first four queues in order, and whichever is first discovered to 
have an entry, one entry is carefully dequeued and processed. Otherwise, if *defer-queue* 
has an entry, all of the entries arc moved to *contra-queu8*for processing. Otherwise, 
if * rebel-queue* has an entry, all entries are separately dequeued and distributed to the 
other rule queues. (The movequeue function could have been used here at the cost have 
having three separate queues *detector-rebel -queue*, *vanil la-rebe l -queue*, and 
*nogood-rebel-queue*.) Failing that, then if *punt-queue* has any entries, the user is 
asked whether they should be moved to *contra-queue* for processing. ( The MSP function 
y-or-n-p queries the user at the terminal by printing the string, then reading a character and 
returning true if y, Y, t, T, space, etc. is typed, or false if n, N, rubout, etc. is typed.) If there is 
nothing at all to do, run ! returns done. 



224 CiiaptfrSix 


Hi i ic;ii:ncy 


(statistics-counter enqueue-rule "Rules enqueued") 

(statistics-counter enqueue-added-rule "Added rules enqueued") 

(statistics-counter enqueue-forget-rule "Forget rules enqueued") 
(statistics-counter enqueue-nogood-rule "Nogood rules enqueued") 

(defun enqueue-rule (rule con reason) 

(require-rule rule) 

(require-constraint con) 

(statistic enqueue-rule) 

(or (eq (rule-ctype rule) (con-ctype con)) 

(lose 'The CTYPE of ~S doesn't match that of ~S." rule con)) 

(let ((queue-item (cons rule con))) 

(select! reason 
((Qadded) 

(statistic enqueue-added-rule) 

(cond ((null (rule-outvar rule)) 

(enqueue queue-item *detector-queue*)) 

((bit-test (§rule-nogood (rule-bits rule)) 

(enqueue queue-item *nogood-queue*)) 

((and (bit-test @rule-nogoodbeg (rule-bits rule)) 

(not (node-boundp (aref (con-values con) (rule-outvar rule))))) 
(enqueue queue-item *nogood-queue*)) 

(t (enqueue queue-item *vani11a-queue*)))) 

((Qforget) 

(statistic enqueue-forget-rule) 

(cond ((or (bit-test @rule-nogood (rule-bits rule)) 

(bit-test @rule-nogoodbeg (rule-bits rule))) 

(enqueue queue-item *nogood-queue*)) 

(t (enqueue queue-item *van i 11 a-queue*)))) 

((Qnogood) 

(statistic enqueue-nogood-rule) 

(and (not (and (bit-test @rule-nogoodbeg (rule-bits rule)) 

(node-boundp (aref (con-values con) (rule-outvar rule))))) 
(enqueue queue-item *nogood-queue*)))))) 

Tablh6-15. Deciding in Which Queue to Fnqucue a Rule. 


6.3.12. The Priority of a Rule Depends on Its Properties 

The function enqueue-rule of 'fable 6-15 is used to make an entry on the standard rule 
queues (those other than * rebel - queue). The function takes a rule, the constraint to apply it to, 
and the reason for the enqueuing. ( The reason is not actually used much here, except to eliminate 
some case-checking. In an early version of this implementation, there was a more complicated 
priority structure that depended on the reason for queuing as well as the characteristics of the rule. 
'Phis complex structure was simplified for the purposes of the current presentation.) The reason 
must be one of the symbolic constants Qadded, Qforget, or Qnogood. 

If the rule has no output pin (this can occur only if the reason is Qadded), then it is a detector 
rule and is enqueued on *detector-queue*. if the rule has the Qnogood or Qnogoodbeg 
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bit set, then it should be enqueued on *nogood-queue*. A Snogoodbeg rule, however, 
should not be enqueued if its output pin has a value already (but this cannot occur if the reason is 
@f orget). In all other cases the rule is enqueued on *vani 11 a- queue*. 


6.3.13. Rule Definitions Explicitly Specify Output Pins 

before examining the details of how rules arc run, it is appropriate to review the new format 
for rule definitions alluded to in §6.2.2 and the conventions for computing values. Recall as an 
example the definition given before for gate: 

(defprim gate (p a b) 

((p) (if (or (= p 0) ( = p 1)) ©dismiss ©lose)). 

((p &nogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (= a b) ©dismiss 0)) 

(b (p a) (if (= p 1) a ©dismiss)) 

(a (p b) (if (= p 1) b ©dismiss))) 

A rule definition may have two or three elements. The last is the body, a single MSP form which 

computes the value. The penultimate form is a list of names of trigger pins. The first of three, 
if present, may be either the name of an output pin, or a list containing the name of an output 
pin and/or keywords. (Following the Lisp Machine LISP convention, keywords begin with 
Currently the only keywords are &nogood and &nogoodbeg (but the syntax allows adding new 
keywords later), which may not be used together and may only be used when an output pin is 
specified. 

The rule body is executed only if all the trigger pins have values. In addition, a &nogoodbeg 
rule need not be run if its output pin already has a value. Within the rule body the names of trigger 
pins may be used as i.,isp variables to refer to the values of the pins (as before). The body should 
return cither an integer or one of the values @lose or Qdismiss, meaning “contradiction” and 
“no value”, respectively. A detector rule is not permitted to return an integer. 
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(statistics-counter run-rule-try "Attempts to run a rule") 

(statistics-counter run-rule-win "Successfully run rules") 

(statistics-counter run-rule-dismiss "Rule runs which dismissed") 

(defun run-rule (queue-item) 

(let ((rule (car queue-item)) 

(con (cdr queue-item))) 

(require-rule rule) 

(require-constraint con) 

(or (eq (rule-ctype rule) (con-ctype con)) 

(lose "The CTYPE of ~S doesn't match that of ~S." rule con)) 

(statistic run-rule-try) 

(setf (con-queued-rules con) (logclr (rule-id-bit rule) (con-queued-rules con))) 
(do-named check-loop 

((tr (rule-triggers rule) (cdr tr))) 

((null tr) 

(ctrace "Running rule ~S on ~S." rule con) 

(statistic run-rule-win) 

(let ((result (funcall (rule-code rule) con))) 

(select result 
((©lose) 

(signal-contradiction (forlist (tr (rule-triggers rule)) 

(aref (con-values con) (car tr))) 
con)) 

((©dismiss) (statistic run-rule-dismiss)) 

(otherwise 

(requ i re-integer result) 

(or (rule-outvar rule) 

(lose "Rule ~S has no output pin but returned ~S." 
rule result)) 

(process-setc con rule result))))) 

(let ((trigger (aref (con-values con) (car tr)))) 

(select! (cell-state trigger) 

((©slave) (or (node-boundp trigger) (return-from check-loop))) 

((©dupe)) 

((©king ©friend ©rebel) 

(or (bit-test ©rule-nogood (rule-bits (cell-rule trigger))) 

(bit-test ©rule-nogoodbeg (rule-bits (cell-rule trigger))) 
(return-from check-loop))) 

((©puppet) (return-from check-loop))))))) 


Table 6-16. Applying a Rule to a Constraint. 
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6.3.14. The Triggers of a Rule Must Have Values When It Is Run 

The function run - rul e ( Table 6-16) takes a queue entry (containing a rule and a constraint) 
from a rule queue and runs the rule on the constraint if appropriate. First the bit in the con¬ 
straints qucued-mlcs component corresponding to the rule’s id-bit is reset, to indicate that the 
rule is no longer on the queue for that constraint. (The MSP function ( 1 ogcl r x y ) performs 
(logand (lognot x) y)— it clears bits of y where x has one-bits.) Next all the triggers of 
the rule arc checked. If a trigger is a slave, then its supplier must have a value. If die trigger is a 
dupe, it necessarily has a value. On the other hand, a puppet never has a value. 

The test in the other three cases may seem a trifle strange: the trigger passes the test only if 
the rule that supplied die value is a &nogood or &nogoodbeg rule. The key is to realize that if 
the trigger is a king, friend, or rebel, then the value must have been computed by the constraint 
we arc considering applying a rule for. Now, there is a convention in this constraint system that no 
ordinary rule ever awakens another rule for the same constraint; the same effect can be achieved by 
letting the second rule’s triggers include those of the first rule and duplicating the first rule’s com¬ 
putation. Such duplication is seldom necessary in practice, and the effort saved by not awakening 
rules is considerable. 

If die triggers pass the test, then the rule code (a MSP function) is applied to the constraint. If 
the result is GTIose, a contradiction is signalled via the function signal -contrad ict ion. If 
it is @dism iss, then a statistic is tallied and nothing else occurs. Otherwise, the result must be 
an integer to be installed as the output pin’s value (there must be an output pin) via the function 
process-setc. 
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(defun process-setc (con rule value) 

(require-constraint con) 

(require-rule rule) 

(require-integer value) 

(let ((cell (aref (con-values con) (rule-outvar rule))) 

(sources (forlist (tr (rule-triggers rule)) 

(aref (ctype-vars (con-ctype con)) tr)))) 

(ctrace "~S computed ~S for its pin ~S~ 

~:[~2*~; from pin~P 

con 

value 

(aref (ctype-vars (con-ctype con)) (cell-name cell)) 
sources 

(length sources) 
sources) 

(process-setc-work con rule value cell))) 

(statistics-counter process-setc-override "Rules which overrode other rules") 
(statistics-counter process-setc-supersede "Rules which superseded other rules") 

Tabu* 6-17. Installing a Computed Value in a Pin (i). 


6.3.15. Installing a Value in a Pin Changes the Pin’s Cell-state 

The function process-setc (Tabic 6-17) does some error-checking, prints a trace message, 
and then hands off the real work to process-setc-work. 

The function process-setc-work (Tabic 6-18) does the error checks all over again (for 
robustness, never trust any code on another page). (Note: when con is () then the given cell is 
(rather, was) a defaul t or parameter cell, and may not be a king, friend, rebel, or dupe. This 
is used by the change function for altering defaults and parameters.) There are then several cases, 
depending on the current cell-state of the pin. 

If the output pin is a king, friend, or rebel, then some other rule of the same constraint has 
already computed a value for the pin. If the new value is not the same as the current value, then 
it is a hard error (rules of die same constraint shouldn’t conflict), unless the rule which computed 
the old value was a &nogood or &nogoodbeg rule, in which case the new value may override 
the old one: the old one is forcibly forgotten, and then the processing restarted (by simply calling 
process-setc-work tail-rccursivcly). If the new value is the same as the old value, then noth¬ 
ing need be done, but as a peculiar heuristic the new rule supersedes the old one as the justification 
if the new rule’s triggers arc a subset of the old one’s triggers—this makes the value less likely to be 
forgotten if an unnecessary trigger is forgotten. However, it is not correct to do this merely because 
the size of the new rule’s trigger set is smaller than that of the old rule: that might introduce 
circular dependency structures. T he new trigger set must be a subset of the old. 
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(defun process-setc-work (con rule value cell) 

(and con (require-constraint con)) 

(require-rule rule) 

(require-integer value) 

(require-cel 1 cell) 

(select! (cell-state cell) 

((©king ©friend ©rebel) 

(or con (lose "No constraint in PROCESS-SETC-WORK?")) 

(cond ((not (equal (cel 1-contents cell) value)) 

(cond ((bit-test @ru1e-nogoodbeg (rule-bits (cell-rule cell))) 
(ctrace "Rule ~S overrides value ~S of rule ~S with ~S." 

rule (cel 1-contents cell) (cell-rule cell) value) 
(statistic process-setc-override) 

(forget cell) 

(process-setc-work con rule value cell)) 

(t (lose "Rules ~S and ~S of ~S disagreed on value for pin ~S 
(respective values were ~S and ~S)." 

(cell-rule cell) 

rule 

con 

(aref (ctype-vars (con-ctype con)) (cell-name cell)) 

(cell-contents cell) 

value)))) 

((contains (rule-triggers (cell-rule cell)) (rule-triggers rule)) 
(statistic process-setc-supersede) 

(self (cell-rule cell) rule)))) ;bogus heuristic 

((©puppet) 

(setf (cel 1-contents cell) value) 

(setf (cell-rule cell) rule) 

(setf (cell-state cell) ©king) 

(awaken-all (node-cells cell) ©added cell)) 

((©slave ©dupe) 

(setf (cel 1-contents cell) value) 

(setf (cell-rule cell) rule) 

(cond ((node-boundp cell) 

(cond ((equal value (node-value cell)) 

(setf (cell-state cell) ©friend)) 

(t (setf (cell-state cell) ©rebel) 

(increment (node-contra cell)) 

(note-rule-contradiction con rule cell)))) 

((eq (cell-state cell) ©dupe) 

(lose "~S was a ©DUPE in a valueless node." cell)) 

(t (usurper cell) 

(setf (cell-state cell) ©king) 

(awaken-all (node-cells cell) ©added cell)))))) 

Tabu- 6-18. Installing a Computed Value in a Pin (ii). 


If the output pin is a puppet, then it can simply be made king, the value installed, and all the 
cells of the node awakened (except the output pin itself—this suppression is accomplished by the 
third argument to awaken-al 1). 

If the output pin is a slave or a dupe, then if the node’s supplier has a value (it must if the pin 
is a dupe!), the output pin becomes a friend or a rebel depending on whether or not the new value 
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agrees with the king’s. If it becomes a rebel, the contra count of the node is incremented, and the 
contradiction created is noted via note-rule-contradiction. 

If the output pin is a slave and the node is supplied by a puppet, then the output pin usurps 
the puppet’s throne, makes itself king, and awakens all the cells excepting itself. (Usurpation causes 
the specified cell to become the supplier of the node.) 
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(a) Rooted at cell X 


(b) Re-rooted at cell Y 


Fjgurh 6-6. Usurping a Supplier. 


(statistics-counter usurper "Usurpations") 

(defun usurper (cell) 

(require-cell cell) 

(statistic usurper) 

(let ((s (node-supplier cell))) 

(point-1inks-toward cell) 

(let ((sc (cell-state cell)) 

(sx (cell-state s))) 

(setf (cell-state s) sc) 

(setf (cell-state cell) sx)))) 

(defun point-1 inks-toward (cell) 

(require-cell cell) 

(do ((x cell (progl (cell-link x) (setf (cell-link x) y))) 

(Y () x)) 

((eq x (node-supplier cell)) 

(setf (cel 1-1 ink x) y) 

(setf (node-supplier cell) cell)))) 

Tabu; 6-19. Usurping the Throne of the Supplier of a Node. 
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6.3.16. Usurping a Supplier Simply Reverses Links from Usurper to Supplier 

The operation of usurpation takes a cell and causes that cell to be the supplier of its node. The 
primary task here is rearrangement of the link components so that all link paths lead to the new 
supplier. This is easy. Consider the path along link edges between the proposed usurper and the 
current supplier. If those edges arc simply reversed in direction, then the desired result is produced. 
An example of this appears in Figure 6-6, wheih depicts the link edges connecting the cells of a 
node. In Figure 6-6a the cell X is the supplier. In Figure 6-6b the cell Y has usurped X, and the 
links along the path from Y to X have been reversed (indicated by heavy arrowheads). 

The function po i nt-1 i nks - toward ( Table 6-19) accomplishes this task. (In structure 
point-1 inks-toward is similar to the MSP function nreverse, which destructively reverses 
a list.) At each step x is a cell along the path from usurper to supplier, and y trails one step 
behind; on each iteration, and at the end, one link edge is reversed. The function usurper calls 
point-1 inks-toward and also then exchanges the cell-states of the usurper and old supplier, 
as a convenience (often this docs the right thing, as when a slave usurps a puppet). 



233 


(defun signal-contradiction (cells con) 

(require-constraint con) 

(ctrace "Contradiction in ~S~@[ among these pins: ~:{~S=~S~:t, 
con 

(forl ist (cell cel 1s) 

(require-cel 1 cel 1) 

(list (aref (ctype-vars (con-ctype con)) (cell-name cell)) 

(cell-value cell)))) 

(enqueue (list* ©constraint 
con 

(forlist (cell cells) 

(require-cel 1 cell) 

(cons cell (cell-value cell)))) 

*contra-queue*)) 

(defun note-rule-contradiction (con rule cell) 

(and con (require-constraint con)) 

(require-rule rule) 

(require-cell cell) 

(or (and (eq (cell-state cell) ©rebel) 

(eq (cell-state (node-supplier cell)) ©king)) 

(lose "~S doesn't conflict with ~S after ail!" cell (node-supplier cell))) 
(and con 

(let ((triggers (forlist (tr (rule-triggers rule)) 

(aref (con-values con) tr)))) 

(ctrace "Contradiction in ~S~@[ among these pins: ~:{~S=~S~:t, 

~/£>;/ | it calculated ~S for ~S from the others by rule ~S." 

con 

(cons (list (aref (ctype-vars (con-ctype con)) (cell-name cell)) 
(node-value cell)) 

(forlist (c triggers) 

(require-cell c) 

(list (aref (ctype-vars (con-ctype con)) (cell-name c)) 

(cell-value c)))) 

(cel 1-contents cell) 

(aref (ctype-vars (con-ctype con)) (cell-name cell)) 
rule))) 

(enqueue (list @node cell (node-supplier cell)) 

*contra-queue*)) 

(defun disallow (&rest cells) 

(dolist (c cells) (require-cell c)) 

(let ((prems (fast-premises* cells))) 

(enqueue (cons ©resolution (forlist (p prems) (cons p (cell-value p)))) 

*con tra-queue*) 

(run?))) 

Table 6-20. Signalling Contradictions. 
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6.3.17. Signalling a Contradiction Merely Queues a Contradiction Task 


The functions signal-contradiction (used by the function run-rule in Table 6-16 
(page 226)) and note-rule-contradiction (used by the function process-setc-work 
in Table 6-18 (page 229)) each signal a contradiction by enqueuing a task to process it later. 
Apparently the only difference between them is the error checks they perform and the trace output 
emitted; however, they enqueue slightly different kinds of tasks. The function s ignal - con trad ict ion 
(Table 6-20) is called when soiuc rule returned @lose to indicate that a contradiction was 
detected without returning a value. In this case the contradiction is blamed on the constraint, and 
a ©constraint contradiction task is enqueued. T he queue entry contains the constraint which 
detected the contradiction, and an association list of pins with values, indicating the trigger values 
that caused the contradiction. This information must be saved because by the time the contradic¬ 
tion task is dequeued for processing the pins may have different values, but the contradiction is 
based on those particular values. If the pins no longer have those values, then the contradiction 
described by the queue entry is no longer in effect. 

On the other hand, note-rule-contradiction enqueues a ©node contradiction task. 

The queue entry contains two cells of the same node which are in conflict, one being the supplier 
(at the time the task is enqueued) and the other a rebel. If when the task is processed the cells no 
longer conflict, th.cn the contradiction is no longer in effect. 

The user function disallow exemplifies the third kind of contradiction task, of type 
©resolution. The queue entry contains an association list of cells and values as for a 
©constraint task, but mentions no constraint. The cells have no local association, but have been 
determined from global considerations to be contradictory when they have those values. Usually 
such a collection of cells is obtained by resolution of nogood sets, but here disallow allows the 
user to specify an arbitrary contradictory set of cells. The collective premises of the cells supplied 
by the user are tracked down and declared contradictory. As with all user interface functions which 
enqueue tasks, disallow finishes by calling run? to enable task scheduling if appropriate. 
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(statistics-counter run-contra "Contradictions dequeued for processing") 
(statistics-counter run-contra-node "0NODE contradictions dequeued for processing") 
(statistics-counter run-contra-constraint 

"©CONSTRAINT contradictions dequeued for processing") 

(statistics-counter run-contra-resolution 

"©RESOLUTION contradictions dequeued for processing") 

(defun run-contra (queue-item) 

(statistic run-contra) 

(setq *rebel-flag* ()) 

(select! (car queue-item) 

((©node) 

(statistic run-contra-node) 

(let ((cl (cadr queue-item)) 

(c2 (caddr queue-item))) 

(require-cel 1 cl) 

(require-cel 1 c 2) 

(or (null (edddr queue-item)) 

(lose "Bad ©NODE contradiction queue item~S." queue-item)) 

(or (not (eq (cell-repository cl) (cel 1-repository cl))) 

(not (eq (cel 1-true-supp!ier cl) cl)) 

(not (eq (cel 1-true-suppIier c2) c2)) 

(and (node-boundp cl) (equal (cell-contents cl) (cel 1-contents c2))) 
(process-contradiction queue-item (edr queue-itern))))) 

((©cons traint) 

(statistic run-contra-constraint) 

(let ((con (cadr queue-item)) 

(alist (eddr queue-item))) 

(require-constraint con) 

(do ((a alist (edr a))) 

((null a) 

(process-contradiction queue-item (forlist (a alist) (car a)) con)) 

(let ((cell (caar a)) 

(val (edar a))) 

(require-cel 1 cell) 

(require-integer val) 

(or (and (node-boundp cell) (equal (ce11-contents cell) val)) 
(return)))))) 

((©resolution) 

(statistic run-contra-resolution) 

(let ((alist (edr queue-item))) 

(do ((a alist (edr a))) 

((null a) (process-contradiction queue-item (forlist (a alist) (car a)))) 
(let ((cell (caar a)) 

(val (edar a))) 

(require-cell cell) 

(require-integer val) 

(cond ((or (not (node-boundp cell)) 

(not (equal (cel 1-contents cell) val))) 

(install-nogood-set 

(forlist (a alist) (cons (cel 1-repository (car a)) (edr a)))) 
(return))))))))) 

Table 6-21. Running a Contradiction Task. 
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6.3.18. Contradictions Must Still Hold at the Time of Processing 

The purpose of the function run-contra (fable 6-21) is to verify that a dequeued con¬ 
tradiction task still describes a contradiction. If the contradiction is still in the network, it is handed 
off to process-contradiction; if not, then the task is dismissed and forgotten. 

There are three kinds of contradiction (©node, ©constraint, and ©resolution), and so 
three cases in the code for run-contra. 

Hor a ©node task, the queue entry contains exactly two cells, which at the time the task was 
queued were cells of the same node asserting different values. The contradiction no longer holds 
if they no longer share a repository (and so arc no longer of the same node—they may have been 
disconnected!); if either is not its own true supplier (if one is now a slave or dupe, then another 
contradiction will have been enqueued involving the new king or rebel, so this one need not be 
processed); if cither has no value; or if their values agree. 

fora ©constraint task, the queue item has a constraint and an association list pairing pins 
of the constraint with values that triggered a contradiction. The contradiction still holds only if all 
the cells still have values matching the paired values. 

For a ©resolution task, the queue item has just an association list pairing cells with values 
that triggered a contradiction. The contradiction still holds only if all the cells still have values 
matching the paired values. If the contradiction docs not now hold, however, it is nevertheless 
important that a nogood set be installed. 
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(defmacro mark-cell (cell val) ‘(self (cell-mark ,cell) ,val)) 

(defmacro unmark-cell (cell) ‘(setf (cell-mark ,cell) ())) 

(defmacro cell-markp (cell) ‘(cell-mark ,ce11)) 

(declare (special ^defaults* *parameters* *nogoods* *default-trees* *links*)) 

(defun fast-premises (cell) 

(require-cell cell) 

(prog ((*defaults* '()) 

(♦parameters* '()) 

(*nogoods* '()) 

(*defau1t-trees* '()) 

(* 1 inks* '())) 

(let ((flag (fast-premises-mark cell))) 

(select flag 

((©lose ©dismiss)) 

(otherwise (push (if (null (cdr flag)) (car flag) cell) 

*def ault-trees*)))) 

(fast-premises-unmark cell) 

(return (append ^defaults* *parameters* *nogoods*) 

*defaults* *parameters* *nogoods* *defaul t-trees* *links*))) 

(defun fast-premises* (cells) 

(prog ((*defaults* '()) 

(*parameters* '()) 

(*nogoods* '()) 

(*default-trees* '()) 

(*1 inks* '{))) 

(let ((flag (fast-premises-mark* cells))) 

(select flag 

((©lose Qd ismiss)) 

(otherwise (setq *default-trees* 

(if (< (length flag) (length cells)) flag cells))))) 
(fast-premises-unmark* cel Is) 

(return (append *defaults* *parameters* *nogoods*) 

♦defaults* *parameters* *nogoods* *default-trees* *links*))) 

Table 6-22. Fast Computation of Premises and Related Quantities. 
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6.3.19. Computation of Premises Also Determines Summarizations of Defaults 

Before we consider the processing of contradictions, it is appropriate to discuss the tracing 
of premises and the determination of an appropriate summarization (as described in §6.2.6). The 
function f ast-prem i ses in Table 6-22 computes not only the list of premises, but also separate 
lists of parameter, default, and “nogood” (assumption) premises, a list of summarizations of 
the defaults (called the “default-trees” because each summarization is the root of a tree whose 
leaves are defaults), and the set of links between cells traversed at each node (this is the set of 
equatings along which the computation traveled). These quantities are accumulated in the I ISP 
special variables bound to empty lists in the prog. The list of premises is simply the concatena¬ 
tion of the lists of defaults, parameters, and assumptions. After fast-premises-mark and 
f ast-premi ses-unmark arc called, all six lists are returned as values, using the Lisp Machine 
MSP multiple-value convention. If f ast-premi ses is called as a simple I ISP function, the list of 
premises is the result (as before), and the other five lists are discarded. All the lists can be obtained 
by using the Lisp Machine l ISP mul t. iple-value-bind construct. 

The function f ast-premi ses* performs the same operation on a list of cells. 

The macros mark-cell, unmark-cell, and cell-markp are operations on the mark 
component of a cell. Note that mark-cel 1 takes an extra argument which is the mark value (thus 
it implements not a mark bit , but a mark quantity. 
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{defun fast-premises mark (cell) 

(require-cell cell) 

(and (node-boundp cell) 

(let ((s (cel1-true-suppl ier cell))) 

(cond ((cell-markp s) 

(and (eq (cell-mark s) t) (lose "Circular dependency at ~S." cell)) 
(cell-mark s)) 

(t (mark-cell s t) ;for error checking! 

(fast-premises-mark-1 inks cell s) 

(let ((result. ( fast-premi ses-mark-test s))) 

(mark-cel 1 s result) 
result.)))))) 

(defun fast-premises-mark-1 inks (x y) 

(prog foo (linksl 1inks2) 

(do ((c x (cel 1-1 ink c ))) 

((null (cell-link c ))) 

(cond ((eg c y) 

(setq slinks* (nconc linksl *links*)) 

(relurn-from foo)) 

(t (push (cons c (cell-link c)) linksl)))) 

(do ((c y (cel 1-1 ink c ))) 

((null (cel 1 - Iin k c ))) 

(cond ((eq c x) 

(setq * links* (nconc 1 i n k s 2 *links*)) 

(return-from foo)) 

(t (push (cons c (cell-link c)) links2)))) 

(setq *links* (nconc linksl links2 slinks*)))) 

(defun fasL-premises-mark-test (s) 

(cond ((eq (cell-rule s) *defau1t-ru1e*) 

(push s *defau1ts*) 

(list s)) 

((eq (cell-rule s) *parameter-rule*) 

(push s *paraineters*) 

@1ose) 

((eq (cell rule s) *constant-ru1e*) ©dismiss) 

((or (hit-test ©rule-nogood (rule-bits (cell-rule s))) 

(hit-test ©ru1enogoodbeg (rule-bits (cell-rule s)))) 

(push s *nogoods*) 

©lose) 

(t (fas t-premises-mark* 

(fori i s t (tr (rule-triggers (cell-rule s))) 

(aref (con-values (cell-owner s)) tr)))))) 

Taw 16-23. Gathering Premise and l ink Information. 


;fast escape 


;fast escape 
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The function fas t-premi ses-mark (Tabic 0-23) is a good deal more complex than 
before. All the information is accumulated in the global variables bound in fast -premises, 
and the functional value of f as t-premi ses-mark is used as a flag. The symbolic constants 
Qdismiss and @lose arc abusively pressed into service here. If the returned value is 
@dismiss then no default, parameter, or assumption cells were encountered in the subtree 
depending from the argument cell. If the returned value is @1 ose then a parameter or assumption 
cell was seen somewhere. Otherwise the returned value is a list of all the default cells found in the 
subtree. 

When a cell is given to f as t-premi ses-mark, its true-supplier is taken. If it is unmarked, 
then the mark is first set to t. Hie operation f as t-p remi ses-ma rk-1 inks accumulates the 
link information between the cell and the true-supplier, and then fas t-premi ses -mark-tes t 
figures out an appropriate return value. This value is then stored in the mark for the true-supplier. 
If this cell is ever encountered again during the tracing of premises, the contents of the mark 
component is returned immediately. An important point is that the value t can never be seen in a 
mark cell—that value is put in only for an error check! If it is seen, then the dependency structure 
must be circular (because there is a t in cells only along the path from the root of the tree being 
searched to the cell currently being considered). 

The function fast-premises mark-1 inks follows the links from the cell and its true- 
supplier, pushing pairs of cells representing equatings onto *1 inks*. Normally the supplier will 
be the node’s supplier, and so the first do loop will get them all. I low ever, if the cell is a dupe and 
the true-supplier a rebel, then there are three cases: 

(1) Follow ing links from the dupe leads to the rebel. 

(2) Following links from the rebel leads to the dupe. 

(3) Following links from cither leads to the node’s supplier before reaching the other. 

All of these cases have to be dealt with properly. 
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(defun fast-preinises-mark* (cells) 

(let ((trees ' ( )) 

(defaults ()) 

(state @d ismiss)) 

( do I i st. ( c cells) 

(let ((result (fast premises-mark c))) 

(select result 

((©lose) (setq state ©lose)) 

((0d i sin i ss)) 

(otherwise 

(push c trees) 

(select state 
((01ose)) 

((©dismiss) (setq state t) (setq defaults result)) 

(otherwise (setq defaults (unionq result defaults)))))))) 

(and (e q state 01o s e) 

(setq *defauIt-trees* 

(nconc (if (< (length trees) (length defaults)) frees defaults) 
♦default-frees*))) 

(if (eq state t) defaults state))) 

( d e f u n f a s t - p rein i s e s - u nma rk (cell) 

(require-cell cell) 

(let ((s (cel I-true-supp1ier cell))) 

( cond ((cel I markp s ) 

(unmark-ceII s) 

(fast p rein i ses - unmark* 

(fori is t. (tr ( rule-triggers (cell-rule s))) 

(aref (con-values (cell owner s)) tr))))))) 

(defun fast-premises-unmark* (cells) 

(dolisf (cell cells) ( f as t. - p rein i ses - unmark cell))) 

I ahi.i: 6-24. Tracing Premises for a list of C 'ells, anti Unmarking. 


I lie function f ast-prem i ses-mark--l.es I. handles the various eases anti tletcrmines the 
value to he returned as described above. If the supplier is not interesting, then the triggers for the 
rule that computed its value are recursively traced using fast-premises-mark* (Table 6-24). This 
function traces each of the given cells, and combines the results. If any of them contains something 
other than a default cell (the value @lose was returned), then @lose must be returned from 
this level, and the subtrees appropriately summarized and added to *defau 11-Trees*. At 
each recursive level of call to f as t-premi ses -ma rk * a heuristic summarization can be done. 
Note that the set-union operation un ionq is used rather than append because subtress may be 
shared, and some of the results may have been obtained from cached lists in the cell marks. All this 
serves to reduce the size of nogood sets as much as possible. 

The functions f ast-prem i ses-mark and fas t-premi ses-mark *, as before, run 
around and reset all the cell marks. 
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(statistics-counter process-contra "Contradictions actually processed") 
(statistics-counter process-contra-auto "Nogood culprits automatically chosen") 

(defun process-contradiction (queue-item cells &optional (con () conp)) 

(and conp (requ i re-constraint con)) 

(statistic process-contra) 

(multiple-value-bind (premises defaults params nogoods trees links) 
(fast-premises* cells) 

(cond ((not (null nogoods)) 

(ctrace "Deeming ~S in ~S (computed by rule ~S) to be the culprit." 
(cell-value (car nogoods)) 

(cell-id (car nogoods)) 

(cell-rule (car nogoods))) 

(statistic process-contra-auto) 

( forin-nogood-set 

(append nogoods params trees)) 

(♦retract (car nogoods))) 

((null premises) (lose "Hard-core contradiction!")) 

((null (cdr premises)) 

(and params (form-nogood-set (append params trees))) 

(♦retract (car premises))) 

(t (and params (form-nogood-set (append params trees))) 

(let ((choice (choose-culprit premises))) 

(select choice 

((Sdefer) (enqueue queue-item *defer-queue*)) 

((Spunt) (enqueue queue-item *punt-queue*)) 

(otherwise (require-cel 1 choice) (*retract choice)))))))) 

Tabu: 6-25. Processing of Contradictions. 


6.3.20. Contradiction Processing Traces Premises and Chooses a Culprit 

Now that f ast-preini ses thoughtfully divides the premises into groups and returns them, 
the task of process-contradiction (Table 6-25) is easier. Itcalles fast-premises using 
multiple-value-bind to get the six return values, and then makes some simple tests. If 
there are any assumptions, a nogood set is formed from the assumptions, the nogoods, and the 
summarizations of defaults, and then the first assumptions is arbitrarily chosen for retraction. If 
there arc no premises at all, it is a hard contradiction. If there is one premise, it is chosen by default 
for retraction, and a nogood set is formed if there arc any parameter cells among the premises. 
Otherwise, choose-cul pri t. is called to select a culprit (and, as in the previous case, a nogood 
set is formed if any parameters arc involved). If choose-culpri t returns @defer or @punt 
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(defun form-nogood-set (cells) 

(setq cells (sort (append cells '()) #'node-lessp)) 

(ctrace "The ser:{~<~X;|~8X~:15,72; ~S=~S~>~:|~8X~:15,72 ; is no good.~>" 
(forlist (c cells) (list (cel 1-goodname c) (cell-value c)))) 

(instal1-nogood-set 

(forlist (c cells) (cons (cel 1-repository c) (cell-value c))))) 

(statistics-counter nogood-set "Nogood sets installed") 

(defun install-nogood-set (alist) 

(statistic nogood-set) 

(let ((nogood (cons 'nogood alist))) 

(dolist (pair alist) 

(let ((rep (car pair)) 

(val (cdr pair))) 

(let ((slot, (assoc val (rep-nogoods rep)))) 

(cond (slot (or (member nogood (cdr slot)) (push nogood (cdr slot)))) 

((or (null (rep-nogoods rep)) 

(< val (caar (rep-nogoods rep)))) 

(push (list val nogood) (rep-nogoods rep))) 

(t (do ((ng (rep-nogoods rep) (cdr ng))) 

((or (nul I (cdr ng)) 

(< val (caar (cdr ng)))) 

(self (cdr ng) 

(cons (list val nogood) 

(cdr ng)))))))))))) 

Tabu; 6-26. Formation and Installation of Nogood Sets. 


(defun choose-cu1pr i t (losers) 

(format t "~°/«; ; ; These are the premises that seem to be at fault: 
~:{~7„:~8X~S~@{ == 

(foriist (p losers) 

(cons p (mapean #'(lambda (c) 

(and (globalp c) 

(eq (cel 1-true-supplier c) p) 
(list (cell-name c)))) 

(node-cel Is p))))) 

(format t ;;; Choose one of these to retract and RETURN it.") 
(let ((culprit (break "Choose Culprit"))) 

(cond ((or (eq culprit ©defer) (eq culprit @punt)) culprit) 
((memq (cel 1-true-supplier culprit) losers) 

(cel 1-true-supplier culprit)) 

(t (choose-culpr i t losers))))) 

Tabu; 6-27. Choosing a Culprit. 


Nogood sets have the same structure that they did in previous versions of the system. 
However, form-nogood-set (Table 6-26) has been split into two functions, one to print a trace 
message and form the nogood a-list, and one (instal 1 -nogood-set) to do the real work. The 
latter function is called from within run-contra (fable 6-21). 
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The function choose-cul pr i t ( I'able 6-27) has changed a bit, to allow the return of the 
flags @defer and @punt in place of a culprit. Also, a contradiction can involve several cells of 
the same node, and if the culprit is identified by returning a cell other than one of die premises, it 
isn’t enough to test that it is in the same node as a premise, for that may not uniquely identify the 
intended culprit. Instead, if an alias is supplied then its truc-supplicr must be one of the premises. 
To aid in this discrimination, a name is printed in the message as an alias only if it is suitable for 
identifying a culprit. 
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(statistics-counter awaken "Awakenings") 

(statistics-counter awaken-added "©ADDED awakenings") 

(statistics-counter awaken-forget "©FORGET awakenings") 

(statistics-counter awaken-nogood "0NOGOOD awakenings") 

(defun awaken (cell reason) 

(require-cel 1 cell) 

(statistic awaken) 

(let ((con (cell-owner cell))) 

(cond ((not (null con)) 

( requ i re-constraint. con) 

(let ((rulearray (select! reason 

((©added) 

(statistic awaken-added) 

(ctype-added-rules (con-ctype con))) 

((©forget) 

(statistic awaken-forget) 

(ctype-forget-rules (con-ctype con))) 

((©nogood) 

(statistic awaken-nogood) 

(cLype-nogood-ruIes (con-ctype con)))))) 

(dolist (rule (aref rulearray (cell-name cell))) 

(or (bit-test (rule-id-bit rule) (con-queued-rules con)) 

(do ((tr (rule-triggers rule) (edr tr)) 

(rebelp ( ) 

(or rebelp 

(let {(v (aref (con-values con) (car tr)))) 
(or (eq (cell-state v) ©rebel) 

(eq (cell-state v) ©dupe)))))) 

((null t r) 

(cond (rebelp (enqueue (list rule con reason) 

* rebel-queue* )) 

(t (enqueue-rule rule con reason)))) 

(or (node-boundp (aref (con-values con) (car tr))) 
(return)))))))))) 

(defun awaken-all (cells reason &optional (exception () exceptionp)) 

(and exceptionp (require-cel 1 exception)) 

(dolist (cell cells) 

(require-cel 1 cell) 

(and (not (eq cell exception)) 

(awaken cell reason)))) 

Taiii.i : . 6-28. Awakening of Rules. 
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6.3.21. Awakening Selects Only Relevant Rules for Queuing 

The rule-array structure for constraint-types is a pre-compilcd catalogue indexing for each pin 
and each reason for awakening which rules should be run. All that awaken ( fable 6-28) need do 
is check that the given cell has an owner, select the appropriate array from the constraint's type, and 
index into the array according to the cell’s pin-number, and wild! all the relevant rules are in hand. 

The rules could simply be enqueued on *vani 11 a-queue* and the system would work. 
However, an attempt is made to avoid enqueuing rules whose triggers do not all have values. ( This 
situation might change between the time the rule is enqueued and the time it is dequeued, but if 
that occurs the rule will be queued any way when llic other triggers gain values.) Also, if any trigger 
is a rebel value then the rule is put on the low-priority * rebel -queue* on the intuition that one 
should compute values that have certain support in preference to those that do not (this can only 
occur anyway if contradictions have been deferred). 

The function awaken-all awakens a list of cells for a specified reason, but will avoid 
awakening a particular cell if that is given as a third argument. This is generally used to awaken all 
the cells of a node except that which generated the value. 
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(statistics-counter forget "Values forgotten") 

(defun forget (cell &optional (source () sourcep) (via () viap)) 
(require-cell cell) 

(and (eq (cell-rule cell) *constant-rule*) 

(lose "Illegal to FORGFT the constant ~S." cell)) 

(and sourcep (require-cell source)) 

(and viap (require-cell via)) 

(statistic forget) 

(ctrace "Removing ~S from ~S~:[~3*~; because ~:[of ~;~S==~]~S~]. " 

(cel 1-contents cell) 

(cell-goodname cell) 
sourcep 

(and viap (not (eq via source))) 

(and viap (not (eq via source)) (ce 11 -goodname via)) 

(and sourcep (ce 1 1-goodname source))) 

(select! (cell-state cell) 

((9 f r i e n d ) 

(self (ce 11-contents cell) ()) 

(self (cell-rule cell) ()) 

(setf (cell-state cell) 0slave)) 

((0rebel) 

(setf (cell-state cell) 0slave) 

(decrement (node-contra cell)) 

(awaken cell 0added) 

(let ((feel 1 sets ' ())) 

(do1 1st (c (rep-cells (cel 1-repository cell))) 

(cond ((and (eq (cell-state c) @dupe) 

(eg (cell-contents c) cell)) 

(setf (cell-state c) ©slave) 

(awaken c ©added) 

(push (cons c (forget-consequences c)) fcel 1 sets)))) 

(dolist (q feellsets) 

(dolist (f (edr q)) 

(forget f coll (car q)))))) 

((©king) 

(do ((x (node-cells cell) (edr x))) 

((null x) 

(forget-friendless-king cell)) 

(cond ((eq (cell-state (car x)) ©friend) 

(usurper (car x)) 

(setf (cel 1-contents cell) ()) 

(setf (cell-rule cell) ()) 

(setf (cell-state cell) ©slave) 

(or (/erop (node-contra cell)) 

(dol ist (c (node-cells cell)) 

(and (eq (cell-state c) ©rebel) 

(enqueue (list @node c (car x)) *contra~queue* )))) 
(return))))) 

((©slave ©puppet ©dupe)))) 

Taiii.i- 6-?.9. Forgetting a Cell's Value and Its Consequences. 
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6.3.22. Forgetting a Cell's Value Lets Friends (Or Rebels) Step In 

When a cell’s value is forgotten, the “begging” process done in previous versions of the system 
need not be performed. It is not necessary to beg a rule to compute a value for its output pin, be¬ 
cause it will do so when it is good and ready and lias all its triggers; and the value, once computed, 
will not be lost because every cell can have a value. (The exceptions arc rules with no triggers—they 
arc invoked when the constraint is generated, or when the status of a nogood set changes if they arc 
&nogood or &nogoodbeg rules. Also, a constraint-type’s ctype-forget-rules array will 
prove very useful for explanation purposes.) 

On the other hand, when a supplier cell's value is forgotten and another cell of the node has 
a value, the second cell may immediately step in as the new supplier for the node (this is the ad¬ 
vantage of recording multiple support for values), and avoid further perturbations of the network. 
If the new value is different, however (provided by a former rebel), then rules need to be awakened 
on the newly added trigger value. Therefore, paradoxically, the forget function only performs 
awakenings for the reason @added! 
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(defuii forget-consequences (cell) 

(let ((feel 1s '())) 

(and (cell-owner cell) 

(doarray (v (con-values (cell-owner cell))) 

(select! (cell-state v) 

((©king @friend @rebel) 

(and (not (eq v cell)) (member (cell-name cell) 

(rule-triggers (cell-rule v))) 

(push v fcells))) 

((©slave ©puppet ©dupe))))) 

fcells)) 

(defun retract (cell) 

(♦retract (ce11-true-supplier cell)) 

(run?)) 

(defun *retract (cell) 

(require-cell cell) 

(ctrace "Retracting the premise ~S." cell) 

(forget cell)) 

(defun change (cell value) 

(require-cell cell) 

(require-integer value) 

(let ((s (cel 1-true-supplier cell))) 

(let ((rule (cell-rule s))) 

(cond ((not (or (eq rule *defau1t-rule*) 

(eq rule *parameter-rule*))) 

(lose "Supplier of ~S is not a DEFAULT or PARAMETER." cell)) 

((or (not (*forbiddenp value s)) 

(y-or-n-p "That value is contradictory; do it anyway?")) 
(♦retract s) 

(process-setc-work () rule value s) 

(run?)))))) 

Tarlh6-30. Retracting a Value, and Tracing of Consequences. 


The actions taken when a cell’s value is forgotten depends on the state of the cell. If it is a 
slave, puppet, or dupe, then nothing need be done, as it has no value. (It might seem at first that 
such a cell should not be forgotten in the first place. However, if x was computed from triggers y 
and z, and y had z as a trigger, and then z is retracted, then when z is forgotten both y and 
x must be forgotten. If y is forgotten, then x is recursively forgotten; it may then become, say, a 
slave. Then x may be forgotten again on account of z.) 

If the cell to be forgotten is a friend, then its value quietly disappears and it becomes a slave to 
the king. No other cell is affected. If it is a rebel, then it and all its dupes become slaves. 'Their rules 
must be awakened for reason Qadded because they all suddenly become aware of the value of the 
king. (Such awakened rules arc not run at once—merely queued for later processing. This is impor¬ 
tant to the integrity of the system; the forgetting process must complete before any rules are run to 
ensure that all computed quantities have well-founded support. (Well-foundedncss is not the same 
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thing as consistency; it merely means that a value is correctly derived from premises. The premises 
need not be consistent, however, for computed values to be well-founded. Indeed, contradictions 
arc detected by the very fact that two well-founded values conflict. Conflicting values that arc not 
well-founded arc not informative.) 

If a king is to be forgotten, then a major upheaval occurs. If the king has a friend, then the 
friend steps into its place. This is the most desirable alternative because the primary value of the 
node docs not change, and slaves need not be bothered. The friend usurps the throne, and if there 
arc any rebels then contradictions tasks for the conflict between the former friend and the rebel 
must be enqueued. 
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(defun forget-friendless-king (cell) 

(require-cel 1 cell) 

(dolist (nogood (edr (assoc (cel 1-contents cell) (node-nogoods cell)))) 

(do ((ng (edr nogood) (edr ng)) 

(unique-loser ())) 

((null ng) 

(and unique-loser 

(awaken-all (rep-cells unique-loser) ©nogood))) 

(and (or (not (node-boundp (rep-supplier (caar ng)))) 

(not (equal (node-value (rep-supplier (caar ng))) 

(edar ng)))) 

(if unique-loser 
(return) 

(setq unique-loser (caar ng)))))) 

(let ((fcellsets '()) (rebel ())) 

(dolist (c (rep-cells (cell-repository cell))) 

(select! (cell-state c) 

((@king ©dupe)) 

((©slave) (push (cons c (forget-consequences c)) fcellsets)) 

((©rebel) (setq rebel c)) 

((©friend) (lose "Already established that ~S had no friends." cell)) 
((©puppet) (lose "©KING ~S and ©PUPPET ~S in same node." cell c)))) 

(cond ((null rebel) 

(setf (cel 1-contents cell) ()) 

(setf (cell-rule cell) ()) 

(setf (cell-state cell) ©puppet) 

(awaken-all (node-cells cell) ©nogood)) 

(t (usurper rebel) 

(setf (cel 1-contents cell) ()) 

(setf (cell-rule cell) ()) 

(setf (cell-state cell) ©slave) 

(decrement (node-contra cell)) 

(awaken cell ©added) 

(dolist (c (rep-cells (cel 1-repository cell))) 

(select! (cell-state c) 

((©slave) (awaken c ©added)) 

((©king)) 

((©rebel) 

(cond ((equal (cel 1-contents c) (cel 1-contents rebel)) 

(setf (cell-state c) ©friend) 

(decrement (node-contra cell))) 

(t (enqueue (list ©node c rebel) *contra-queue*)))) 
((©dupe) 

(and (equal (cel 1-contents (cell-contents c)) 

(cel 1-contents rebel)) 

(setf (cell-state c) ©slave))) 

((©puppet ©friend) 

(lose "Impossible cell state for~S." c)))))) 

(dol ist (q fcellsets) 

(do!ist (f (edr q)) 

(forget f cell (car q)))))) 

Table6-31. Forgetting a Friendless King (Very Hairy!). 



252 Chapter Six 


Fihcif.ncy 


If a king to be forgotten has no friends, then several things happen (performed by the function 
forget-friendl ess-king in 'fable 6-31). First of all, it is the king that affect nogood sets 
(nogood sets being per-node instead of per-cell), so if a king disappears then all the nogood sets of 
the node for the disappearing value must be checked. If all the other nodes but one in a nogood set 
have their associated values, then the disappearance of this king might unblock an assumption for 
the lone node not having its paired value; rules for that node (called the unique-loser in the 
code) must be awakened. 

After the nogood awakenings are taken care of, then all the consequences of forgetting the 
king must be enumerated. The variable f cell sets is a list of buckets; each bucket is headed by 
a slave of the king, and contains immediate consequences of that slave. These consequences will 
be forgotten in turn, but not until the state of the current node has been resolved. (It was much 
easier to write the forget function if it could be assumed that every node encountered was in 
a consistent state, rather than in a half-forgotten state.) The function forget-consequences 
( fable 6-30) enumerates the consequences of a cell by examining all the pins of that cell’s con¬ 
straint and finding those pins for which the given cell was a trigger. (By the way, this enumeration 
of consequences is also done when a rebel is forgotten—see fable 6-29.) 

While the consequences arc being enumerated, it is noted whether there is any rebel. If there 
is not, then the king becomes a puppet, and the node loses its value, whereupon Snogood rules 
must be given a chance to run. (This would be the obvious place to run @f orget rules, but, as 
already noted, this is unnecessary.) Otherwise, one rebel is chosen arbitrarily (the last one seen) to 
become the new king. It usurps the old king, which becomes a slave. The total number of rebels 
for the node is decreased by one. Then every other cell of the node must be examines. Slaves are 
awakened to the new value. Other rebels either become friends (in which case the count of rebels 
is decremented) or remain rebels (in which case a contradiction with die new king is enqueued). 
Dupes of rebels which arc to become friends arc turned into slaves; they need not be awakened, as 
they already knew of the “correct” value. Puppets cannot occur in node which has a value, and by 
supposition the old king was friendless, so no friends can be encountered. 

The function retract (Table 6-30) is now die user interface to the retraction mechanism. 
It calls * retract to do the work on the given cell’s true-supplicr (in that way the user 
can say (retract centigrade) to specify retraction of the default cell connected to 
cent i grade, for example). Then run? is called to allow queued tasks to be processed. 

The function change will change the value of a default or parameter cell. If the value is 
forbidden by a nogood set, it asks the user before blundering onward. It then retracts the old value, 
installs the new one (by pretending to do a se tc-typc operation), and then runs the task scheduler. 
(This implementation is extremely simple-minded. Although it checks the nogood sets, if the value 
is found to be contradictory it docs not immediately enqueue a contradiction on the basis of the 
nogood set (which would not be hard to do). Instead, the computation will truly blunder onward 
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(defmacro the (x y) ‘(*the ' ,x ,y)) 

(defun *the (name con) 

(require-constraint con) 

(or (lookup name con) (lose "~S has no part named ~S." con name))) 

(defun lookup (name thing) 

(require-constraint thing) 

(let ((names (ctype-vars (con-ctype thing))) 

(cells (con-values thing))) 

(let ((n (array-length names))) 

(do ((j 0 (+ j 1))) 

((= J n) ()) 

(and (eq (aref names j) name) (return (aref cells j))))))) 
Tabu-:6-32. Referring lo Pins Using the. 


until the contradiction is rediscovered. [ was feeling lazy the day 1 wrote this code. A more 
complicated idea would be to take advantage of the fact that a value was not being retracted, but 
merely changing. This would involve running rules while the forget process was only half done, 
and would require great care. However, it is certainly what people do when adjusting constrained 
values.) 


6.3.23. The 1 ookup Functions Scans the Constraint-types's vars Array 

The the macro, and its utility function *the, are now primarily for user interface since the 
implementation now deals internally with pin-numbers rather than pin-names, flic 1 ookup func¬ 
tion scans the vars array of the constraint-type, and if the name is found returns the corresponding 
component of the constraint’s values array. 
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(statistics-counter equatings "Number of calls to = = ") 

(defun == (celll cell2) 

(require-cel 1 celll) 

(require-cel 1 ce112) 

(statistic equatings) 

(let ((xl (inemq celll (cell-equivs cel!2))) 

(x2 (inemq cell2 (cell-equivs celll)))) 

(cond ((or xl x2) 

(or (and xl x2 (eq (ce11-repository celll) (cel 1-repository cell2))) 
(lose "LQUIVS lists not consistent for ~S and ~S.” celll cell2))) 
((not (eq celll cell2)) 

(push celll (cell-equivs cell2)) 

(push ce112 (cell-equivs celll))))) 

(or (eq (cel 1-repository celll) (cel 1-repository cell2)) 

(let ((rl (cel I-repository celll)) 

( r2 (cell-repository ce112)) 

(cbl (node-boundp celll)) 

(cb2 (node-boundp ce!12))) 

(let ((r (merge-values celll cell2)) 

(rcells (append (rep-cells rl) (rep-cells r2)))) 

(let ((newcomers (if cbl (if cb2 '{) (rep-cells r2)) 

(if cb2 (rep-cells rl) '()))) 

(xr (if (eq r rl) r2 rl))) 

(setf (rep-cells r) rcells) 

(dolist (cell (rep-cells xr)) (setf (ce11 - repository cell) r)) 

(let ((fcells (alter-nogoods-rep xr r))) 

(setf (rep-nogoods r) 

(merge-nogood-sets (rep-nogoods r) (rep-nogoods xr))) 
(awaken-all fcells ©nogood)) 

(awaken-all newcomers ©added) (run?) 

'done))))) 

Table 6-33. Equating of Cells and Recording Equatings Explicitly. 
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6.3.24. Equatings arc Recorded Explicitly and Initialize Links 

When an equating is done (using ==), it must be explicitly recorded even if it is redundant 
by transitivity. (See Table 6-33.) If this exact equating between these exact two cells has already 
been done, then it need not be recorded twice; otherwise each cell is added to the other’s equivs 
list. (Therefore the equatings arc recorded redundantly, in that each equating is recorded twice, 
one in each cell. This is mostly for pleasant symmetry and error-checking, and is not crucial to the 
implementation.) 

Once this is done, then the rest of the work is relevant only if the cells arc currently of 
two different nodes (determined by comparing their repositories). If they are of different nodes, 
then merge-values is called to compare the values. In this version, merge-values will not 
only compare the values and detect contradictions, but also rearrange the cell links and do other 
housekeeping. It returns as its value the repository of the node which is to provide the supplier for 
the merged node. The rest of == is pretty much as before. The set of newcomers is determined, 
the node structure is updated, the nogood sets are merged, cells may be awakened on account 
of the nogood sets, and the newcomers are awakened (they could be awakened right after they 
are determined, for awakening merely enqueues now; but I was lazy and left the code similar to 
previous versions —it doesn’t hurt). 
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(defun merge-values (cel 11 cell2) 

(require-cel 1 celll) 

(requ i re-cel 1 cell2) 

(let ((rl (cell-repository celll)) 

(r2 (cell-repository cell2))) 

(cond ((not (node-boundp celll)) 

(let ((s (rep-supplier rl))) 

(or (eq (cell-state s) ©puppet) 

(lose "Valueless node had a non-@PUPPET supplier ~S." s)) 
(setf (cell-state s) ©slave)) 

(point-1inks-toward celll) 

(setf (cell-link celll) cel 12) 

r 2 ) 

((not (node-boundp ce112)) 

(let ((s (rep-supplier r2))) 

(or (eq (cell-state s) ©puppet) 

(lose "Valueless node had a non-@PUPPET supplier ~S." s)) 
(setf (cell-state s) ©slave)) 

(point-1inks-toward cell2) 

(setf (cell-link ce!12) celll) 
rl) 

(t (let ((r (cond ((eq (node-rule celll) *constant-rule*) rl) 

((eq (node-rule ce!12) ^constant-rule*) r2) 
((ancestor celll cel!2) rl) 

((ancestor ce!12 celll) r2) 

((plusp (rep-contra r2)) rl) 

(t r2 )))) 

(if (eq r rl) 

(merge-two-values r r2 celll cell2) 

(inerge-two-values r rl ce!12 celll))))))) 

Table 6-34. Merging Values and Arranging Cell Links. 


The function merge-values (Table 6-34) is responsible for deciding which node will 
provide the repository (and thus the supplier) for the merged node. It is also reponsible for install¬ 
ing a new cell link. The new link will always be between the two cells given to = = ; this guarantees 
that links follow paths laid down by explicit equatings. My initial impulse was to link the deposed 
supplier to the surviving supplier, because then all the other links need not be changed to preserve 
the property that the links lead eventually to the supplier. However, this fails to preserve the 
property of following explicit equatings. The solution is that the given cell of the node not provid¬ 
ing the repository must usurp its own supplier. Then link paths from all cells of that node will 
lead to that given cell, and thence to the other given cell, and so to the surviving supplier. ITe 
function po i nt-1inks-toward is used instead of usurper (see fable 6-19 (page 231)) to 
avoid changing the cell states (it doesn’t much matter in the cases occuring in fable 6-34, because 
the deposed supplier has been made into a slave). 
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(defun merge-two-values (r xr cell xcell) 

(let ((val (cel 1-contents (rep-supplier r)))) 

(cond ((and (zerop (rep-contra xr)) 

(equal (cel 1-contents (rep-supplier xr)) val)) 

(setf (cell-state (rep-supplier xr)) @friend)) 

(t (ctrace "Contradiction when merging ~S and ~S." cell xcell) 
(dolist (c (rep-cells xr)) 

(select! (cell-state c) 

((@slave) 

(cond ((not (equal (cell-contents (node-supplier c)) val)) 
(setf (cell-state c) @dupe) 

(setf (ce11-contents c) (rep-supplier xr))))) 

((@rebel @k ing @fr iend) 

(cond ((equal (cel 1-contents c) val) 

(setf (cell-state c) Sfriend)) 

(t (setf (cell-state c) Qrebel) 

(increment (rep-contra r)) 

(enqueue (list Snode c (rep-supplier r)) 
♦contra-queue*)))) 

((Sdupe) 

(and (equal (cell-contents (cel 1-contents c)) val) 

(setf (cell-state c) Qslave))) 

((@puppet) (lose "Puppet ~S in a bound node." c))))))) 
(point-1inks-toward xcell) 

(setf (cell-link xcell) cell) 

«*) 

Table 6-35. Merging Two Nodes with Values and Handling Conflicts. 


If both cells have values, then one is chosen on the basis of certain criteria, some of them 
heuristic. Constants arc preferred for surviving kings. Barring that, the avoiding of circular de¬ 
pendency structures is paramount. If tliat does not resolve the issue, then nodes with internal 
contradictions are less desirable than consistent nodes. Once a repository has been chosen, then the 
rest of the work is handed off to me rg e -1 wo - v a 1 u e s ('Fable 6-35). 

If the node whose king is being deposed (represented by xr and xcell) is free of con¬ 
tradiction, and the two values agree, then the situation is particularly easy and is handled as a 
special case. The deposed king becomes a a friend of the surviving king, and his old friends and 
slaves automatically become friends and slaves of the surviving king, and that is that. Otherwise 
a contradiction has occurred—either the deposed king or one of his rebels must disagree with the 
surviving king. All the cells of the xr node are processed. Slaves to a disagreeing old king become 
dupes. (Note that the phrase (cel 1-contents (node-supplier c)) is used rather than 
the seemingly equivalent (node-value c); this is done because node-value performs an 
important error-check that must be circumvented here because the node is temporarily in a bad 
situation.) Rebels, friends, and the king may become cither friends or rebels, depending on the 
values involved. Dupes may become slaves if their associated rebels become friends. When all this 
is done, and contradictions have been enqueued, the cell links arc set up and the chosen repository 
returned. 
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(defun alter-nogoods-rep (xr r) 

(let ((feel 1s '())) 

(dolist (bucket (rep-nogoods xr)) 

(dolist (nogood (edr bucket)) 

(let ((z (assq r (edr nogood))) 

(xz (assq xr (edr nogood)))) 

(cond ((null xz) 

(lose "Funny nogood set ~S for bucket ~S of repository ~S." 
xr (car bucket) nogood)) 

((null z) 

(setf (edr nogood) 

(add-nogood-pa i r r (edr xz) (delassq xr (edr nogood))))) 
((equal (edr z) (edr xz)) 

(setf (edr nogood) (delassq xr (edr nogood)))) 

(t (dolist (pair (edr nogood)) 

(setq feells (append (rep-cells (car pair)) fcells)) 

(let ((buck (assoc (edr pair) (rep-nogoods (car pair))))) 

(or buck (lose "Nonexistent bucket: ~S.” pair)) 

(setf (edr buck) (delq nogood (edr buck))) 

(or (edr buck) 

(setf (rep-nogoods (car pair)) 

(delrassq '() (rep-nogoods (car pair)))))))))))) 

fcells)) 

(defun add-nogood-pair (rep val nogoodlist) 

(require-repository rep) 

(cond ((null nogoodlist) (list (cons rep val))) 

((node-lessp (car (rep-cells rep)) (car (rep-cells (caar nogoodlist)))) 
(cons (cons rep val) nogoodlist)) 

(t (cons (car nogoodlist) (add-nogood-pair rep val (edr nogoodlist)))))) 

(defun merge-nogood-sets (si s2) 

(cond ((null si) s2) 

((null s2) si) 

((< (caar si) (caar s2)) 

(cons (car si) (merge-nogood-sets (edr si) s2))) 

((> (caar si) (caar s2)) 

(cons (car s2) (merge-nogood-sets si (edr s2)))) 

(t (cons (cons (caar si) (merge-nogood-buckets (edar si) (edar s2))) 
(merge-nogood-sets (edr si) (edr s2)))))) 

(defun merge-nogood-buckets (bl b2) 

(cond ((null bl) b2) 

((member (car bl) b2) (merge-nogood-buckets (edr bl) b2)) 

(t (cons (car bl) (merge-nogood-buckets (edr bl) b2))))) 

Tablh 6-36. Altering and Merging of Nogood Sets. 


The code for altering and merging of nogood sets is unchanged, because the representation of 
nogood sets is the same. For completeness the code is reproduced here in Table 6-36. 
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(defun ancestor (celll cell2) 

(require-cel 1 celll) 

(require-cel 1 cel12) 

(or (eq (cel 1-repository celll) (cel 1-repository cell2)) 

(select! (cell-state cell2) 

((©king ©rebel) (ancestor-triggers celll cell2)) 

((@friend) (ancestor-triggers celll (node-supplier cel 12))) 
((©slave) (and (node-boundp ce!12) 

(ancestor-triggers celll (node-supplier ce112)))) 

((©puppet) ()) 

((©dupe) (ancestor-triggers celll (cel 1-contents cell2)))))) 

(defun ancestor-triggers (celll cell2) 

(require-cell celll) 

(require-cel 1 cel!2) 

(do ((tns (rule-triggers (cell-rule ce!12)) (cdr tns))) 

((nul 1 tns) ()) 

(and (ancestor celll (aref (con-values (cell-owner cel 12)) (car tns))) 
(return t)))) 

Tabu- 6-37. Testing Ancestorhood. 


The tracing of ancestors by the function ancestor is similar in spirit if not in implementa¬ 
tion to previous versions. The code appears in fable 6-37. Note that a dependency chain might 
actually wind through a single node more than once, if the node contains rebels. It might wind in 
through a dupe, out through a rebel; in through a slave, out through the king; in through another 
dupe, and so on. I’hc low priority accorded to rules triggered by rebels and dupes is intended to 
avoid such occurrences, but it can legitimately happen. 
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(defun dissolve (cell) (^dissolve cell) (run?)) 

(defun ^dissolve (cell) 

(requi re-cel 1 cell) 

(fast-expunge-nogoods cell) 

(let ((supplier (node-supplier cell)) 

(cells (node-cells cell))) 

(ctrace "Dissolving ~{~<;/| ~2,72:;~S~>~t, .” 

(forlist (c cells) (cell-goodname c))) 

(dolist (c cells) 

(setf (cell-link c) ()) 

(setf (cell-equivs c) '()) 

(or (eq c supplier) 

(let ((r (gen-repository))) 

(select! (cell-state c) 

((@friend ©rebel) 

(setf (cell-state c) ©king)) 

((©dupe ©slave) 

(or (node boundp supplier) 

(setf (cell-state c) ©puppet))) 

((©king ©puppet) 

(lose "©KING or ©PUPPET ~S was not the supplier." c))) 
(setf (rep-supplier r) c) 

(setf (cell-repository c) r) 

(push c (rep-cel Is r))))) 

(setf (node-cells supplier) (list supplier)) 

(setf (node-contra supplier) 0) 

(and (node-boundp supplier) 

(let ((feel Is '())) 

(dolist (c cells) 

(select (cell-state c) 

((©slave ©dupe) 

(setf (cell-state c) ©puppet) 

(setq fcells (nconc (forget-consequences c) fcells))))) 
(dolist (f fcells) (forget f))))) 

' done) 

Tabu* 6-38. Dissolving a Node. 


6.3.25. Node Disconnections Can be Done by Dissolving and Reconnecting 

When a node is dissolved, things arc a little complicated, because friends and rebels can be¬ 
come kings. On the other hand, the former nonsense about restoring values to default and constant 
cells pleasantly vanishes here. Ihe function dissolve (Tabic 6-38) tears all the cells of a node 
apart and generates new repositories for each one but the supplier. (A supplier does not have to be 
chosen artificially for a valueless node, because there is always a supplier, even if only a puppet.) 
The cell links and recorded equivalences arc obliterated. If the node had had a supplier, then any 
cells which had been slaves or dupes will no longer have values, and so arc subject to the forgetting 
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process. Therefore they arc left marked as slaves or dupes until late in the process, until their 
consequences have been recorded for forgetting, whereupon they become puppets. 
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(defun detach (cell) (*detach cell) (run?)) 

(defun *detach (cell) 

(require-cel 1 cell) 

(dolist (c (cell-equivs cell)) 

(setf (cell-equivs c) (delq cell (cell-equivs c)))) 

(setf (cell-equivs cell) ()) 

(reconstruct-node cell)) 

(defun disconnect (cell) (*disconnect cell) (run?)) 

(defun ^disconnect (cell) 

(require-cel1 cell) 

(dolist (c (cell-equivs cell)) 

(setf (cell-equivs c) 

(unionq (reinq c (cell-equivs cell)) 

(delq cell (cell-equivs c))))) 

(setf (cell-equivs cell) ()) 

(reconstruct-node cell)) 

(defun disequate (cell 1 ce!12) (*disequate celll cell2) (run?)) 

(defun *disequate (celll cell2) 

(require-cel 1 celll) 

(require-cel1 cel 12) 

(and (eq (cel 1-repository celll) (cel 1-repository ce112)) 

(let ({xl (niemq celll (cell-equivs cell2))) 

(x2 (meinq cell2 (cell-equivs celll)))) 

(cond ((and xl x2) 

(setf (cell-equivs celll) (delq ce!12 (cell-equivs celll))) 

(setf (cell-equivs ce!12) (delq celll (cell-equivs cell2))) 

(and (or (eq celll (cell-link cel 12)) 

(eq cel 12 (cell-link celll))) 

(reconstruct-node celll))) 

((or xl x2) 

(lose "Inconsistent EQUIVS lists for~S and ~S." celll cel 12))))) 

' done) 

(defun reconstruct-node (cell) 

(require-cel 1 cell) 

(let ((equivs ' ()) 

(*run-flag* ())) 

(dolist (c (node-cells cell)) 

(dolist (e (cell-equivs c)) 

(push (cons c e) equivs))) 

(♦dissolve cel 1) 

(dolist (q equivs) 

(== (car q) (cdr q)))) 

(run?)) 

Tabu- 6-39. Detaching, Disconnecting, and Discounting Cells. 


Rather than implementing all the special cases for disconnecting, detaching, and disequating, 
which arc rather horrendous in their details, for ease of implementation I borrowed an idea from 
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L. Peter Dcutsch: to change the connections of just a few cells, simply dissolve the whole node and 
then rc-asscrt all the equatings except the ones to be abolished. This carries a time penalty, but 
makes implementation much easier. 

Table 6-39 contains the code for detach, disconnect, and disequate. The first is 
defined to pretend that all equatings involving a given node had never taken place. The function 
♦ detach removes the cell from the cquivs lists of all cells it had been equated to, erases the 
equatings of the given cell, and then calls reconstruct-node to do the dirty work. 

The function disconnect is defined to remove itself from the node but otherwise leave 
the node intact, so it must add new equatings among all the things to which it had formerly been 
connected, to ensure that they do not become disconnected. The work function *detach removes 
the given cell from cquivs lists, set-unions its own cquivs list into its former buddies' cquivs lists, 
erases its own connections, and then calls recons true t-node. 

The function disequate must undo any equating between the two given cells. Nothing 
need be done if they had not already been equated, but if they had then ♦d isequate deletes 
each from the other’s cquivs list (after some error-checking), but only needs to reconstruct the node 
if deleting the equating affected the node’s cell-links structure. 

The interesting part is in reconstruct-node. It is defined to take a node whose cquivs 
lists have been messed with and make the node structure consistent with those lists. It makes up a 
list of equatings to be done, dissolves the node, and then calls == to do each equating. (Because 
the equatings arc recorded redundantly, as described in §6.3.24, twice as many calls as necessary 
arc made to = = ; but this doesn’t hurt anything.) This is done with ♦run-flag-* bound to () 
to prevent tasks from running until the node is reconstructed—no use in computing values on the 
basis of a false network structure! 



264 Chapter Six 


Riticihncy 


(defmacro mark-node (cell) ‘(self (node-mark ,cell) t)) 

(defmacro unmark-node (cell) ‘(setf (node-mark ,cell) ())) 
(defmacro markp (cell) ‘(node-mark ,cell)) 

(defun fast-expunge-nogoods (cell) 

(require-cel 1 cell) 

(fast-expunge-nogoods-mark cell) 

(fast-expunge-nogoods-unmark cell)) 

(defun fast-expunge-nogoods-mark (cell) 

(require-ce11 cell) 

(cond ((not (markp cell)) 

(mark-node cel 1) 

(and (not (null (node-nogoods cell))) 

(awaken-all (node-cells cell) Snogood)) 

(setf (node-nogoods cell) '()) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(doarray (v (con-values (cell-owner c))) 
(fast-expunge-nogoods-mark v))))))) 

(defun fast-expunge-nogoods-unmark (cell) 

(require-cel 1 cell) 

(cond ((markp cell) 

(unmark-node cell) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(doarray (v (con-values (cell-owner c))) 

(f ast-expunge-nogoods-unmark v))))))) 

Table 6-40. Fast Expunging of Nogood Information. 


When a node is dissolved, this implementation follows previous implementations in simply 
expunging all the nogood information in the entire network. Now that premises computes 
the precise equivalences involved in a contradiction, it would not be so difficult to add this infor¬ 
mation to a nogood set when it was formed, and to cross-reference nogood sets in each node 
containing an equivalence mentioned in a nogood set. Then when a node was dissolved, only 
relevant nogood sets need be expunged. However, this involves saving a great deal of information 
as data structures, which may not be worth it, and so 1 have not investigated this technique. Note 
that fast-expunge-nogoods-mark ('fable 6-40) awakens every cell it encounters for reason 
Onogood , which can lake a while to process. Fortunately, there are not that many rules which 
awaken on that condition. 
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ro destroy (symbol) ‘(♦destroy symbol)) 

♦destroy (symbol) 
ire-symbol symbol) 

(boundp symbol) 

(let ((val (symeval symbol))) 

(cond ((cell-p val) 

(cond ((and (globalp val) (eq (cell-name val) symbol)) 
(♦detach val) 

(makunbound (cell-id val)) 

(makunbound symbol)) 

(t (lose "Illegal re-declaration of ~S." symbol)))) 

((constraint-p val) 

(cond ((eq (con-name val) symbol) 

(forarray (p (con-values val)) (*detach p)) 
(makunbound symbol)) 

(t (lose "Illegal re-declaration of ~S.” symbol)))) 
((or (constraint-type-p val) (repos i tory-p val) (rule-p val)) 
(lose "Illegal re-declaration of ~S." symbol)) 

(t (makunbound symbol))))) 

) 

Tablu 6-41. Destroying the Value tjf a Global Name. 


6.3.26. Destroying a Variable or Constraint Detaches It from Everything 

At last we may discuss the function ^destroy referred to in §6.3.9. It is used by create 
and variable ('fable 6-11 (page 217)) as well as by destroy ('fable 6-41). The function 
^destroy takes a I.1SP symbol, and if that symbol has a value examines that value. If the value 
is a cell, then the cell must be global and have the symbol as its name; otherwise the user must 
be trying to destroy one of the generated unique debugging id names, flic cell is detached, and 
the symbol made to have no value (the lisp function makunbound removes the value from a 
symbol). Similarly, if the value is a constraint, then if the symbol is the constraint’s name, the 
constraint’s pins arc all detached. It is illegal to destroy the name for a constraint-type, or the id for 
a repository or rule. A name not used to name any of the system data structures may be destroyed. 
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(defprim (adder +) (c a b) 

(c (a b) (+ a b)) 

(b (a c) (- c a)) 

(a (b c) (- c b))) 

(defprim (multiplier *) (c a b) 

(c (a) (if (zerop a) 0 ©dismiss)) 

(c (b) (if (zerop b) 0 ©dismiss)) 

(c (a b) (* a b)) 

(h (a c) (if (and (not (zerop a)) (zerop (\ c a))) 

(// c a) 

©dismiss)) 

(a (b c) (if (and (not (zerop b)) (zerop (\ c b))) 

(// c b) 

©dismiss))) 

(deTpriin (maxer max) (c a b) 

(c (a b) (max a b)) 

(b (a c) (cond ((< a c) c) 

((> a c) ©lose) 

(t ©dismiss))) 

(a (b c) (cond ((< b c) c) 

((> b c) ©lose) 

(t @dismiss)))) 

(defprim (minner min) (c a b) 

(c (a b) (min a b)) 

(b (a c) (cond ((> a c) c) 

((< a c) ©lose) 

(t @d isiniss))) 

(a (b c) (cond ((> b c) c) 

((< b c) ©lose) 

(t @dismiss)))) 

(defprim (equality =) (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (= a b) 1 0)) 

(b (p a) (if (= p 1) a ©dismiss)) 

(a (p b) (if (= p 1) b ©dismiss))) 

(defprim gate (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 l))) 

(p (a b) (if (= a b) ©dismiss 0)) 

(b (p a) (if (= p 1) a ©dismiss)) 

(a (p b) (if (= p 1) b ©dismiss))) 

TABUi6-42. Definition of Primitive Constraint-types (i). 
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(defprim (lesser <) (a b) 

((a b) (if (< a b) ©dismiss ©lose))) 

(defprim (lesser! <!) (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (< a b) 1 0))) 

(defprim (lesser? <?) (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (< a b) ©dismiss 0))) 

(defprim (?lesser ?<) (a b) 

((a &nogoodbeg) (b) (if (forbiddenp (- b 1)) ©dismiss (- b 1))) 

((b &nogoodbeg) (a) (if (forbiddenp (+ a 1)) ©dismiss (+ a 1))) 

((a b) (if (< a b) ©dismiss ©lose))) 

(defprim (?lesser! ?<!) (p a b) 

((p) (if (or (= p 0) (- p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

((a &nogoodbeg) (bp) 

(let ((guess (if p (- b 1) b))) (if (forbiddenp guess) ©dismiss guess))) 
((b &nogoodbeg) (a p) 

(let ((guess (if p (+ a 1) a))) (if (forbiddenp guess) ©dismiss guess))) 
(p (a b) (if (< a b) 1 0))) 

(defprim (?lesser? ?<?) (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p &nogoodbeg) () (resolve-among '(0 1))) 

((a &nogoodbeg) (bp) 

(if (and p (not (forbiddenp (- b 1)))) (- b 1) ©dismiss)) 

((b &nogoodbeg) (a p) 

(if (and p (not (forbiddenp (+ a 1)))) (+ a 1) ©dismiss)) 

(p (a b) (if (< a b) ©dismiss 0))) 

Table 6-43. Definition of Primitive Constraint-types (ii). 
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(defprim (?niaxer ?max) (cab) 

(c (a b) (max a b)) 

((c &nogoodbeg) (a) (if (forbiddenp a) a ©dismiss)) 

((c &nogoodbeg) (b) (if (forbiddenp b) b ©dismiss)) 

(b (a c) (cond ((< a c) c) 

((> a c) @1ose) 

(t ©dismiss))) 

(a (b c) (cond ((< b c) c) 

((> b c) 01ose) 

(t @dismiss)))) 

(defprim (?minner ?min) (c a b) 

(c (a b) (min a b)) 

((c &nogoodbeg) (a) (if (forbiddenp a) a ©dismiss)) 

((c &nogoodbeg) (b) (if (forbiddenp b) b ©dismiss)) 

(b (a c) (cond ((> a c) c) 

((< a c) ©lose) 

(t ©dismiss))) 

(a (b c) (cond ((> b c) c) 

((< b c) ©lose) 

(t @d ismiss)))) 

(defprim signum (s a) 

((s) (if (or (= s -1) (= s 0) (= s 1)) ©dismiss ©lose)) 

((s Snogoodbeg) () (rosolve-among '(-1 0 1))) 

(a (s) (if (zerop s) 0 ©dismiss)) 

(s (a) (cond ((plusp a) 1) ((nvinusp a) -1) (t 0)))) 

(defprim (assumption assume) (pin) 

((pin &nogoodbeg) () (if (forbiddenp *info*) ©dismiss *info*))) 

(defprim oneof (pin) 

((pin &nogoodbeg) () (choose-from *info*)) 

((pin) (if (member pin *info*) ©dismiss ©lose))) 

(defprim firstoneof (pin) 

((pin &nogood) () (choose-from *info*))) 

Tabi.h6-44. Definition of Primitive Constraint-types (iii). 


6.3.27. Primitive Constraints Are Uniformly Defined by def p r im 

In Chapter Five, the definition of most primitive constraints was done via the defprim con¬ 
struct, blit the “strange” constraint-types assumption, oneof, and firstoneof were defined 
“manually”, that is, by jerry-rigging the rule and constraint-type structures. Here we have a more 
general defprim that can accommodate rules which depend on nogood information. 

The format of rule definitions was discussed in §6.3.13. Bach rule specification has an optional 
output pin-name and keywords, a list of trigger pin-names, and a body. The definitions of adder, 
multiplier, maxer, minner, equality, and gate appear in Table 6-42. They are pretty 
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much as in previous versions, with three exceptions. One is that setc and contradiction 
arc not used, but instead cither an integer or one of the two flags @lose and ©dismiss is 
computed. Another is that equal i ty and gate each have a new rule, the second one. The first 
rule of each states that p must be 0 or 1, or else a contradiction occurs. The second rule says that if 
one of the two values 0 and 1 is forbidden by a nogood set, then the other one can be deduced and 
tentatively asserted. (The function resol ve-among checks the nogood sets. It does not really 
do resolution—it merely checks whether one unique value of a set is possible, and if so asserts it; 
it is the value which will cause resolution if it fails.) The third exception is that if in place of the 
name is a list of two symbols, then the first is the name and the second is the c type-symbol to 
be used by tree-form when extracting an algebraic expression from the network. If no separate 
ctype-symbol is supplied, the name is used. (This feature is primarily to make the output 
prettier. One might ask why the name is not always used, for if one wants adders to be called “+” 
in algebraic forms one could always just use the name + instead of adder. T he answer is that 
the name is used for interacting with the I isp system, and the I ISP system already uses the name 
+ for something else. T hus this feature is a compromise with I isp, yielded in exchange for all the 
advantages using I ISP provides.) 


Table 6-43 defines some new primitive constraint-types. Definitions for them appeared in §6.1. 
A lesser device enforces a numerical less-than relationship between its two pins a and b—its 
rule signals a contradiction if this is not so. The ?lesser device is similar, but also will try a 
heuristic guess at the value of one pin if the other is known. The first two rules arc assumption 
(&nogoodbeg) rules which define the heuristic that in the absence of better information the two 
pins might as well have adjacent integers as values. This device is useful for expressing geometrical 
spacing constraints, for example. One might specify that one object must be somewhere to the left 
of (have an x-coordinatc less than that of) another object; then in the absence of better information 
they will be right next to each other. The form f o rb i ddenp is a predicate true iff the given value 
is disallowed by existing nogood sets. 


The device types lesser! and lesser? are to lesser as equal i ty and gate are 
to ==, in effect. Type lesser! provides an extra pin p which specifics whether the lesser 
relationship between a and p is true or false. Type lesser? uses not a biconditional but an 
implication; if p is 1 then die lesser relationship holds, but if p is 0 the relationship may or 
may not hold. The device types ?1 esser! and /z?lcsscr! have the same relationships to the type 
?1 esser. (1 have found that having three such versions of almost any constraint-type is useful. A 
more advanced constraint language might just automatically provide every constraint-type with two 
extra pins p? and p! which arc initially assumed to be 1. This would be one way for a constraint 
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(defun ass 

ume (value) 




(let ((a 

(gen-constraint assumption 

(gen- 

-name ' 

assumption)))) 

(setf 

(con-info a) value) 




(the p 

in a))) 




(defun oneof (valuelist) 




(let ((a 

(gen-constraint oneof (gen 

-name 

'oneof 

)))) 

(setf 

(con-info a) valuelist) 




(the p 

in a))) 




(defun firstoneof (valuelist) 




(let ((a 

(gen-constraint firstoneof 

(gen 

-name ' 

firstoneof ) ))) 

(setf 

(con-info a) valuelist) 




(the p 

in a))) 





Ta mi;0-45. The assume. 

oneo 

f, and 

firstoneof Constructs. 


network to control itself—by turning the p? pin on and off to turn constraints on and off. 5 ) 

The constraint-types ?maxer and ?minner (fable 6-44) are like ?lesser—each is willing 
to make a guess on the basis of partial information. In this case, if one of a and b is known and 
the other not, then c is assumed to be the same as the known pin. 

file constraint-type signum illustrates a situation where a pin is confined to a value set of 
more than two elements. The pin s must be one of —1, 0, or 1, reflecting the sign of the pin 
a. The first rule checks the value space; the second allows deduction of a value if the other two 
are forbidden; the third deduces a = 0 from s = 0; and the fourth is the obvious definition of 
signum as a function of a. 

After these odd definitions, those of assumption, oneof, and f i rstoneof are not very 
surprizing. Hie one rule for assumption says that the rule need not be invoked unless the out¬ 
put pin has no value, in which case the assumed value is asserted unless forbidden. The first rule for 
oneof chooses among the possibilities and returns one (choose- f rom is like resol ve-among 
except that it always returns some one choice or else performs resolution; resol ve-among will 
fail to return a choice unless it is forced). The second rule checks that a value computed elsewhere 
is in its value set. 

The one rule for f i rstoneof is a &nogood rules rather than a &nogoodbeg rule. That 
means that it will let a nogood set stop a value, but not the output pin. It chooses a value on the 
basis of nogood sets alone, and then returns it. If the output pin already has a value, it can jolly well 
cause a contradiction and create a nogood set, whereupon the rule, when run again, will then admit 
a different choice. 

5. Luc Steels provides a similar facility in his constraint system [Sieels 1980], where by convention every constraint 
has an extra “enable” pin, ITic name of this pin is the name of the constraint itself, and so he speaks of using the 
constarint itself as a value. 1 view the constraint and its enable pin as distinct things, and mean something else by 
using a constraint as a value. 'Ibis is discussed in the Conclusions chapter. 
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The implementation of the assume, oneof, and firstoneof constructs is pretty much 
as in Chapter Five, except that the rules involved need not be explicitly awakened; the function 
gen -constraint (Table 6-11 (page 217)) hikes care of that. 
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(defmacro defprim (namespec vars . rules) 

(let ((name (if (atom nainespec) namespec (car namespec))) 

(symbol (if (atom namespec) namespec (cadr namespec)))) 

‘(progn 'compile 

(declare (special ,name)) 

(setq ,name (make-constraint-type)) 

(setf (ctype-name ,name) ',name) 

(setf (ctype-symbol ,name) symbol) 

(setf (ctype-vars ,name) (array-of ',vars)) 

(setf (ctype-added-rules ,name) (array-n ,(length vars))) 
(setf (ctype-forget-rules ,narne) (array-n ,(length vars))) 
(setf (ctype-nogood-rules ,name) (array-n ,(length vars))) 
(defmacro ,(symbolconc name "-VAHNUM") (varname) 

‘(posq varname ',',vars)) 

(defmacro ,( symbol cone name "-I3INDCFLLS" ) body 
‘(let ,',(forlist (var vars) 

*(,(symbol cone var "-CELL") 

(aref (con-values *ine*) ,(posq var vars)))) 

,0body)) 

,@(do ((r rules (edr r)) 

(bit 1 (1s h bit 1)) 

(defs '() (cons ‘(defrule ,name ,bit 

,@(if (null (eddr (car r))) 

(cons () (car r)) 

(car r))) 

defs))) 

((null r) defs)) 

' ( ,name primitive)))) 

Tahi.h 6-46. Definition of Primitives. 
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(defprim gate (p a b) 

((p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

((p Snogoodbeg) () (resolve-among '(0 1))) 

(p (a b) (if (= a b) ©dismiss 0)) 

(b (p a) (if (- p 1) a ©dismiss)) 

(a (p b) (if (= p 1) b ©dismiss))) 

expands inlo: 

(progn 'compile 

(declare (special gate)) 

(setq gate (make-constraint-type)) 

(setf (ctype-name gate) 'gate) 

(setf (ctype-symbol gate) 'gate) 

(setf (ctype-vars gate) (array-of '(p a b))) 

(setf (ctype-added-ruIes gate) (array-n 3)) 

(setf (ctype-forget-rules gate) (array-n 3)) 

(setr (ctype-nogood-rules gate) (array-n 3)) 

(defmacro gate-varnum (varname) 

‘(posq ',varname '(p a b))) 

(defmacro gate-bindcel1s body 

‘(let ((p-cell (aref (con-values *me*) 0)) 

(a-cell (aref (con-values *me*) 1)) 

(b-cell (aref (con-values *me*) 2))) 

,@body)) 

(defrule gate 16 a (p b) (if (= p 1) b ©dismiss)) 

(defrule gate 8 b (p a) (if (= p 1) a ©dismiss)) 

(defrule gate 4 p (a b) (if (= a b) ©dismiss 0)) 

(defrule gate 2 (p &nogoodbeg) () (resolve-among '(0 1))) 

(defrule gate 1 () (p) (if (or (= p 0) (= p 1)) ©dismiss ©lose)) 

'(gate primitive)) 

Tahi.p. 6-47. Expansion of ihe Definition of gate. 


Table 6-46 shows the new definition of the LISP macro defprim. Among other things, it 
assigns id-bits to each of the rules (each id-bit is a distinct power of two). It also defines two macros 
name- varnum and naine-b indcel 1, references to which will be generated by defrule. One 
converts a pin-name into a pin-number, and the other generates the binding of names of the form 
pin-name -cell to the corresponding cells, which is done in every rule. Using macros in this 
way instead of a global data base causes the information to be transmitted correctly at cither lisp 
compile time or LISP interpretation time, 'fable 6-47 shows the LISP code into which the defprim 
definition of gate expands. 
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(defmacro defrule (typename bit output-stuff trigger-names body) 

(let ((rulename (gen-name typename 'rule)) 

(ctype (symeval typename)) 

(output-name (cond ((null output-stuff) ()) 

((atom output-stuff) output-stuff) 

(t (car output-stuff)))) 

(keywords (cond ((atom output-stuff) ()) 

(t (cdr output-stuff))))) 

(require-constraint-type ctype) 

‘(progn 'compile 

(declare (special ,rulename)) 

(defun ,rulename (*me*) 

(let ((*rule* ,rulename) 

(*info* (con-info *me*))) 

(,(symbo1 cone typename "-BINDCELLS") 

(let ((*outvar* ,(if output-name 

(symbolconc output-name "-CELL") 

())) 

,@(forlist (var trigger-names) 

‘(,var (cell-value ,(symbolconc var "-CELL"))))) 
.body)))) 

(let ((rule (make-rule))) 

(setq ,rulename rule) 

(setf (rule-code rule) ',rulename) 

(setf (rule-ctype rule) ,typename) 

(setf (rule-outvar rule) 

,(if output-name 

‘(,(symbolconc typename "-VARNUM") ,output-name) 

())) 

(setf (rule-triggers rule) 

(list ,@(forlist (var trigger-names) 

*(,(symboI cone typename "-VARNUM") ,var)))) 

(setf (rule-bits rule) 

,(+ (if (memq '&nogood keywords) @rule-nogood 0) 

(if (memq '&nogoodbeg keywords) @rule-nogoodbeg 0))) 
(setf (rule-id-bit rule) ,bit) 

,@(and output-name 

‘((push rule (aref (ctype-forget-rules ,typename) 

(,(symbol cone typename "-VARNUM") 

,output-name))))) 

,@(forlist (var trigger-names) 

‘(push rule (aref (ctype-added-rules ,typename) 

(,(symbol cone typename "-VARNUM") ,var)))) 
,@(and (or (memq '&nogood keywords) (memq '&nogoodbeg keywords)) 
‘((push rule (aref (ctype-nogood-rules ,typename) 

(,(symbol cone typename "-VARNUM") 

,output-name )))))) 

'(,typename rule)))) 

Tabu* 6-48. Definition of Rules. 


Table 6-48 shows the new definition of the LISP macro defrule. It arranges to create the rule 
data structure and catalogue it in the constraint-type’s rules tables. 
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(defrule gate 2 (p &nogoodbeg) () (resolve-among '(0 1))) 
expands into: 

(progn 'compile 

(declare (special gate-rule-69)) 

(defun gate-rule-69 (*me*) 

(let ((*rule* gate-rule-69) 

(♦info* (con-info *me*))) 

(gate-bindeel1s (let ((*outvar* p-cel 1)) (resolve-among '(0 1)))))) 
(let ((rule (inake-rul e))) 

(setq gate-rule-69 rule) 

(setr (rule-code rule) 'gate-rule-69) 

(setf (rule-ctype rule) gate) 

(setf (rule-outvar rule) (gate-varnum p)) 

(setr (rule-triggers rule) (list)) 

(setf (rule-bits rule) 2) 

(setf (rule-id-bit rule) 2) 

(push rule (aref (ctype-forget-rules gate) (gate-varnum p))) 

(push rule (aref (ctype-nogood-rules gate) (gate-varnum p)))) 

'(gate rule)) 


(defrule gate 1 () (p) (if (or (= p 0) (= p 1)) ©dismiss @lose)) 
expands into: 

(progn 'compile 

(declare (special gate-rule-70)) 

(defun gate-rule-70 (*me*) 

(let ((♦rule* gate-rule-70) 

(♦info* (con-info *me*))) 

(let ((p-celI (aref (con-values *me*) 0)) 

(a-cell (aref (con-values *me*) 1)) 

(b-cell (aref (con-values *me*) 2))) 

(let ((*outvar* nil) 

(p (cell-value p-cell))) 

(if (or (= p 0) ( = p 1)) ©dismiss ©lose))))) 

(let ((rule (make-rule))) 

(setq gate-rule-70 rule) 

(setf (rule-code rule) 'gate-rule-70) 

(setf (rule-ctype rule) gate) 

(setf (rule-outvar rule) nil) 

(setf (rule-tr iggers rule) (list (posq 'p '(p a b)))) 

(setf (rule-bits rule) 0) 

(setf (rule-id-bit rule) 1) 

(push rule (aref (ctype-added-rules gate) (posq 'p '(p a b))))) 
'(gate rule)) 

Tabus 6-49. Expansions of the Definitions of Two gate Rules. 
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(defmacro forbiddenp (val) ‘(*forbiddenp ,val *outvar*)) 

(statistics-counter forbiddenp-sets "Number of nogood sets checked") 
(statistics-counter forb iddenp-pa i rs "Number of nogood set pairs checked") 

(defun *forbiddenp (val *outvar*) 

(do-named outer-loop 

((x (cdr (assoc val (node-nogoods *outvar*))) (cdr x))) 

((null x) ()) 

(statistic forbiddenp-sets) 

(do-named inner-loop 

((c (cdar x) (cdr c))) 

((null c) 

(return-from outer-loop (car x))) 

(statistic forb iddenp-pairs) 

(and (not (eg (caar c) (cel 1-repository *outvar*))) 

(or (not (eq (cell-state (rep-supplier (caar c))) ©king)) 

(not (equal (ce 11-contents (rep-supplier (caar c))) (cdar c)))) 
(return-Trom inner-loop))))) 

Table 6-50. Checking Whether a Value is Forbidden by a Nogood Set. 


Table 6-49 shows the expansions of two of the rules for the gate constraint-type. The first 
one does not have the occurrences of gate-b i ndeel 1 s and gate-varnum expanded, and the 
second one does. (The MSP function posq treats its second argument, a list, as a zero-origin array, 
and returns the index into that array of the first occurrence of its first argument, using an eq test.) 


6.3.28. Checking the Nogood Sets Can Advise Rules about Forbidden Values 

The utility macro f o rb i ddenp used by many of the primitive’s rule definitions is defined in 
Table 6-50. It calls the function *forb iddenp on the specified value and the cell for the output 
pin of the rule. (This is yet another example of providing a function for internal use and a macro 
that makes the interface pretty in common situations (rule definitions in this case).) It is essentially 
the check in the old code for assumption-rule in Table 5-2 (page 143). If a nogood set can 
be found that forbids the old value, it is a “killer” and is returned; if none is found then () is 
returned. 

In a similar manner the macros choose-from and resol ve-among interface to functions 
named *choose-f rom and * resol ve-among. Each of them is based on the outer loop of die 
old oneof - rul e in fable 5-3 (page 144). Each of them tests elements from the list of possibilities 
using forbiddenp, and for each forbidden value adds the killer to an accumulating list. Each 
of them signals a contradiction of none of the possibilities work (and then returns @d i smi ss, not 
@1 ose—the contradiction is enqueued by signal - nochoice, and it is not correct to blame this 
contradiction on the rule which invoked a macro, because it is a ©resolution-type contradic¬ 
tion). The difference between them is that if a valid possibility is found *choose-f rom returns it 




§6.3.28 The New Improved Implementation 277 

immediately, whereas *resol ve-among checks them all, and returns ©dismiss unless there is 
a unique choice. 
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(definacro choose-froin (choices) 

‘(*choose-from ,choices *outvar*)) 

(defun *choose-from (choices *outvar*) 

(do ((v choices (cdr v)) 

(killers '())) 

((null v) 

(signal-nochoice choices *outvar* killers) 

@dismiss) 

(let ((ng (forbiddenp (car v)))) 

(if ng (push ng killers) (return (car v)))))) 

(defun signal-nochoice (choices *outvar* killers) 

(ctrace "All of the values ~S for ~S are no good." 
choices 

(cell-goodname *outvar*)) 

(let ((losers '())) 

(dolist (killer killers) 

(dolist (x (cdr killer)) 

(or (eq (car x) (cel 1-repository *outvar*)) 

(or (assq (rep-supplier (car x)) losers) 

(push (cons (rep-supplier (car x)) (cdr x)) losers))))) 
(enqueue (cons ©resolution losers) *contra-queue*))) 

(defmacro resolve-among (choices) 

‘(*resolve-among ,choices *outvar*)) 

(defun *resolve-among (choices *outvar*) 

(do ((v choices (cdr v)) 

(winners '()) 

(killers '())) 

((null v) 

(cond ((null winners) 

(s ignaI-nochoice choices *outvar* killers) 

©dismiss) 

((null (cdr winners)) (car winners)) 

(t ©dismiss))) 

(let ((ng (forbiddenp (car v)))) 

(if ng (push ng killers) (push (car v) winners))))) 

TaisU' 6-51. Filtering a Set of Possibilities Using Nogood Sets. 


The functions choose-froin and resolve appear in Table 6-51. So does the function 
s ignal -nochoice, which performs the resolution step on a set of killer nogood sets. It produces 
a new resolvent set, and enqueues a @resolut ion-type contradiction task. 
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(defun why (cel 1) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) 

(format t has no value." (cell-id cell)) 

(let ((flag ())) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(dolist (rule (aref (ctype-forget-rules 

(con-ctype (cell-owner c))) 

(cell-name c))) 

(let ((trigger-names 

(forlist (tr (rule-triggers rule)) 

(aref (ctype-vars (con-ctype (cell-owner c))) tr)))) 
(format t I could compute it~;~ 

; o r~ ]" 

flag) 

(setq flag t) 

(format t "; from ~:[~2*~;pin~P ~} of ~]~ 

~S by rule ~S" 
tr igger-names 
(length trigger-names) 
tr igger-names 
(con-name (cell-owner c)) 
rule))))) 

(format t I don't have any way to compute it.~;.~]" flag))) 

(t (format t "~%;The value ~S is in ~S because " 

(cell-value cell) (cel 1-goodname cell)) 

(select! (cell-state cell) 

((@king @friend Qrebel) 

(why-how cell)) 

((@slave) 

(format t "it is connected to ~S~%; and " 

(cell-goodname (node-supplier cell))) 

(why-how (node-supplier cell))) 

((Qdupe) 

(format t "it is connected to ~S~%; and " 

(cel 1-goodname (cel 1-contents cell))) 

(why-how (cel 1-contents cell))) 

((©puppet) (lose "Bound node has a ©PUPPET cell ~S." cell))))) 

'q.e.d.) 

Tabi.h 6-52. Implementation of the why Function. 


6.3.29. The why Function Prints Values Forbidden by Nogood Sets 

The new definition of the why function appears in Table 6-52. As before, it divides into two 
cases depending on whether or not the given node has a value. If it docs, then it dispatches on the 
cell-state of the given cell to determine just how it got its value. Note that why and all the other 
explanation functions are carefully written to be useful on contradictory networks—they handle 
rebels and dupes properly. They don’t require consistency, merely wcll-foundcdncss. 
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(defun why-how (s) 

(if (null (cell-owner s)) 

(format t "that is a constant.") 

(format t ~0,72:;~S computed it~>~<~%; ~0,72:; using rule ~S~>~ 

~@[~7o; from: ~:{~S CS)~:[~*~; = 

(cell-owner s) 

(cel 1-rule s) 

(forlist (tr (rule-triggers (cell-rule s))) 

(let ((cell (aref (con-ctype (cell-owner s)) tr))) 

(list (cel 1-id cell) 

(aref (ctype-vars (con-values (cell-owner s))) tr) 
(node-boundp cell) 

(cell-value cell)))))) 

(print-forbidden-values s)) 

(defun print-forbidden-values (s) 

(and (node-boundp s) 

(or (bit-test Qrule-nogood (rule-bits (cell-rule s))) 

(bit-test @rule-nogoodbeg (rule-bits (cell-rule s)))) 

(format t "~@[~%;Nogood sets currently forbid these values: ~{~S~t.~]" 

(mapcan ^'(lambda (x) (and (*forbiddenp (car x) s) (list (car x)))) 
(node-nogoods s))))) 

(defun ce11-goodname (cell) 

(require-cel 1 cell) 

(cond ((globalp cell) (cell-name cell)) 

((or (eq (cell-rule cell) ^constant-rule*) 

(eq (cell-rule cell) *default-rule*) 

(eq (cell-rule cell) *parameter-rule*)) 

(list (cell-name cell) (cell-contents cell))) 

(t (list 'the (aref (ctype-vars (con-ctype (cell-owner cell))) 

(cell -name cell)) 

(con-name (cell-owner cell)))))) 

Tabu; 6-53. Fxplaining a True-Supplier, and Priming Forbidden Values. 
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The function why-how (Tabic 6-53) prints the constraint, rule, and triggers that were respon¬ 
sible for a computed value, and then calls print-forbidden-values to check for any values 
that arc forbidden by nogood sets. Of course, the set of all possible values is infinite, being all 
the integers, but print-forbidden-values simply maps over the buckets of the nogoods 
component of a node, and for each bucket value checks to sec whether it is forbidden. After all, a 
value cannot be forbidden if there is no bucket to hold a killer for it! 

The function cel 1 -goodname tries to pick a pretty name for a cell for printing purposes. 
This version never uses the cell-id, which the user isn’t ever supposed to sec anyway. 

As an example, consider this interaction (with tracing turned off): 

(test) ;set up a temperature conversion network 

DONE 

(== fahrenheit (default -40)) 

DONE 

(why centigrade) 

; T h e value -40 is in CENTIGRADE because it is connected to (THE B MULT) 

; and <MULT:MULTIPLIER> computed it using rule <B«-MULTIPLIER-RULE-5(A,C)> 
from: CELL-271 (A) = 9, CELL-269 (C) = -360. 

Q.E.D. 

As another example, suppose that the network for the four queens problem of §5.4.2 has been 
run in the new system. 

(why qO) 

;The value 1 is in QO because it is connected to (THE PIN ONEOF-250) 

; and CONEOF-250:0NE0F> computed it 
; using rule <(PIN &NOGOODBEG)«-ONEOF-RULE-44( )> . 

;Nogood sets currently forbid these values: 0. 

Q.E.D. 

(why ql) 

;The value 3 is in Ql because it is connected to (THE PIN ONEOF-253) 

; and CONEOF-253:0NE0F> computed it 
; using rule <(PIN &N0G00DBEG)<-0NE0F-RULE-44( )> . 

;Nogood sets currently forbid these values: 0,1,2. 

Q.E.D. 

Of course, a value is forbidden for q n only when it is assumed that all the other q /' arc fixed. 
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(defun why-ultimately (cell) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) 

(format t has no value." (cell-id cell)) 

(format t "~@[ Perhaps knowing the value of 

~: 15,72 ; ~S ~>~tor ~}would help.~]" 

(forlist (c (delq cell (desired-premises cell))) (cell-name c)))) 
(t (format t "~7;The value ~S is in ~S because ” 

(cell-value cell) (cel 1-goodname cell)) 

(select! (cell-state cell) 

((@king @friend Qrebel) (why-ultimately-how cell cell)) 

((Qslave) 

(format t "it is connected to "S~%; and " 

(ce11-goodname (node-supplier cell))) 

(why-ultimately-how cell (node-supplier cell))) 

((Qdupe) 

(format t "it is connected to ~S~7,; and " ( cel 1 -con tents cell)) 
(why-ultimately-how cell (cel 1-goodname (cel 1-contents cell)))) 
((Spuppet) (lose "Hound node has a ©PUPPET cell ~S." cell))))) 

'q.e.d.) 

(defun wliy-u 1 timately-how (cell s) 

(if (null (cell-owner s)) 

(format t "that is a constant.") 

(multiple-value-bind (premises defaults params nogoods trees links) 
(fast-premises cell) 

(format t "it was ultimately derived" 

~@[ from:~:{~7„; ~S~@ == ~S~~: tJ . ~ 

"@["7;These connections were involved:" 

~:{~7o; ~S == ~S~: t 
(forlist (p premises) 

(cons p (inapcan it'( lambda (c) 

(and (globalp c) (list (cell-name c)))) 
(node-cells p)))) 

(forlist (1 links) 

(list (cel 1-goodname (car 1)) (cel 1-goodname (cdr 1)))))))) 
Tablh6-54. Implementation of why-ul timately. 


6.3.30. The why-ul t imately Function Prints Cell-Link Information 

The function why-ul timately (Table 6-54) has been split into two functions in the same 
way that why was. The function why-ul timately-how prints not only the premises which 
support the quantity asked about, but also all the equating connections traversed by the computa¬ 
tion (using the links information computed by premises). As an example, consider this 
explanation for the temperature conversion network: 


(test) 

DONE 

(== fahrenheit (default -40)) 


;set up a temperature conversion network 
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(defun desired-premises (cell) 

(require-cel 1 cell) 

(progl (desired-premises-mark cell) (desired-premises-unmark cell))) 

(defun desired-premises-mark (cell) 

(require-cel 1 cell) 

(cond ((and (not (node-boundp cell)) 

(not (markp cell))) 

(mark-node cell) 

(do ((c (node-cells cell) (cdr c)) 

(p '() (nconc (if (null (cell-owner (car c))) 

(and (globalp (car c)) (list (car c))) 

(des ired-premises-constraint (car c))) 

P))) 

((null c) p))))) 

(defun desired-premises-constraint (cell) 

(require-cel 1 cell) 

(let ((p '())) 

(dolist (rule (aref (ctype-forget-rules (con-ctype (cell-owner cell))) 

(cell-name cel 1))) 

(dolist (tr (rule-triggers rule)) 

(setq p (nconc (desired-premises-mark 

(arof (con-values (cell-owner cell)) tr)) 

P)))) 

P)) 

(defun desired-premises-unmark (cell) 

(require-cel 1 cell) 

(cond ((markp cell) 

(unmark-node cell) 

(dolist (c (node-cells cell)) 

(and (cell-owner c) 

(doarray (pin (con-values (cell-owner c))) 

(desired-premises-unmark pin))))))) 

TABU: 6-55. Locating Desired Premises for an Unbound Cell. 


DONE 

(why-ultimately centigrade) 

;The value -40 is in CENTIGRADE because it is connected to (THE B MULT) 
; and it was ultimately derived from: 

; <CELL-292 (DEFAULT-290) KING -40> == FAHRENHEIT. 

;These connections were involved: 

; (THE B OTHERMULT) == (CONSTANT 5), 

; FAHRENHEIT == (DEFAULT-290 -40), 

; (THE C ADD) == FAHRENHEIT, 

; (THE B ADD) == (CONSTANT 32), 

; (THE A OTHERMULT) == (THE A ADD), 

; (THE C MULT) == (THE C OTHERMULT), 

; (THE A MULT) == (CONSTANT 9), 

; CENTIGRADE == (THE B MULT). 

Q.E.D. 
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(defun what (cell) 

(require-cel 1 cell) 

(cond ((not (node-boundp cell)) 

(format t "~7 n ;~S has no value. I can express it in this way:~ 

~S = ~S~" 

(cell-id cell) (tree-form cell t))) 

(t (format t "~%;The value ~S in ~S was computed in this way:~ 

~S «- ~S~" 

(cell-value cell) (cei1-goodname cell) (tree-form cell)))) 
(print-forbidden-values (cel 1-true-suppIier cell)) 

' okay?) 

(defprop assumption disliked treeformpref) 

(defprop oneof disliked treeformpref) 

(defprop firstoneof disliked treeformpref) 

(defmacro nummark (cell) 

1 (setf (cell -mark ,cel1) 

(if (numberp (cell-mark ,cell)) (+ (cell-mark ,cell) 1) 1))) 
(defmacro unnummark (cell) ‘(setf (cell-mark ,cell) ())) 

(defmacro nummarkp (cell) ‘(numberp (cell-mark ,cell))) 

(defmacro singlenummarkp (cell) ‘(equal (cell-mark ,cell) 1)) 

(defun tree-form (cell Soptional (shallow ())) 

(require-ce 11 cell) 

(nummark (cel 1-true-supplier cell)) 

(prog2 (tree-form-trace cell shallow) 

(tree-form-gather cell shallow) 

(tree-form-unmark cell))) 

Table6-56. Implementation of what. 


The code for desired-premises (Table 6-55) is essentially as before, with minor 
modifications for the new data structures involved. 


6.3.31. The wha t Function Uses the Generalized Algebraic Form 

The only change to the function what ('fable 6-56) is the addition of a call to the function 
print-forbidden-values (defined in Table 6-53). All of the interesting changes arc in the 
function t ree - f o rm and its cohorts. 

I couldn’t resist using property lists for something (this is LISP code, after all!), and so 
die property treeformpref on the name fo a constraint-type indicates whether that type 
of constraint may be used to express the value of a cell. Possible values arc disliked 
and forbidden, though forbidden isn’t used here. Types assumption, oneof, and 
firstoneof arc disliked; they are not used in algebraic expressions if there is any better alterna¬ 
tive. 
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(defun tree-form-trace-set (owner names shallow) 

(require-constraint owner) 

(do ((n names (cdr n)) 

(queue '() (nconc (tree-form-tag (aref (con-values owner) (car n))) queue))) 
((null n) (dolist (c queue) (tree-form-trace c shallow))))) 

(defun tree-form-tag (cell) 

(require-cel 1 cell) 

(let ((s (cel 1-true-suppl ier cell))) 

(and (not (progl (nummarkp s) (nummark s))) 

(list cell)))) 

(defun tree form-trace (cell shallow) 

(require-cel 1 cell) 

(cond ((node-boundp cell) 

(let ((s (ce11-true-supplier cell))) 

(cond ((cell-owner s) 

(or shallow 

(tree-form-trace-set (cell-owner s) 

(rule-triggers (cell-rule s)) 
shallow))) 

(t (nummark s))))) ;crock 

(t (let ((cells (node-cells cell))) 

(usurper (or (if shallow 

(or (tree-form-shallow cell cells) 

(tree-form-deep cell cells shallow)) 

(or (tree-form-deep cell cells shallow) 
(tree-form-shallow cell cells))) 

(progn (and (cell-owner cell) 

(tree-form-trace-set 
(cell-owner cell) 

(fortimes (j (array-length 

(con-values 

(cell-owner ce l I)))) 

j) 

shallow)) 

cell))))))) 

Tablk 6-57. Tracing Out an Algebraic Expression in the Network. 


'The code for tracing out an expression (Table 6-57) is not changed much. It operates on the 
truc-supplicr of the given cell if it is bound. If the node has no value, then any supplier will do, 
and the existing puppet could be used. However, tree-f orm- trace tries as before to choose 
a “good” artificial supplier and lets it usurp the existing puppet. (It is somewhat of a “no-no” to 
have a probing utility such as what alter the network being probed—it violates the principle that 
debugging tools should avoid altering the object being debugged in unpredictable ways. This is 
a very tiny violation, though. If the node structure is sound, it doesn’t matter which cell is the 
puppet.) 
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(defun tree-form-shallow (cell cells) 

(do ((c cells (cdr c))) 

((null c) ()) 

(and (not (eq (car c) cell)) 

(globalp (car c)) 

(return (car c))))) 

(defun tree-form-deep (cell cells shallow) 

(do ((z cel Is (cdr z )) 

(any ())) 

((null z) any) 

(and (not (eq (car z) cell)) 

(cell-owner (car z)) 

(let ((pref (get (ctype-name (con-ctype (cell-owner (car z)))) 

' treeformpref))) 

(cond ((eq pref 'dislike) (setq any (car z))) 

((not (eq pref 'forbidden)) 

(tree-form-trace-set 

(cell -owner (car z)) 

(fortimes (j (array-length (con-values (cell-owner (car z))))) 

j) 

shallow) 

(return (car z)))))))) 

Tablh 6-58. Determining a "Good" Artificial Supplier. 


The new version of tree-form-deep (fable 6-58) uses the preferences expressed by the 
treeformpref property to avoid using a disliked constraint-type in an algebraic expression. A 
forbidden one is never, ever used; a disliked one is used only if therre aren’t any others. 
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(declare (special *cuts* *allcuts* *extra-equations*)) 

(defun tree-form-gather (cell shallow) 

(require-cel 1 cell) 

(do ((*cuts* (list cell)) 

(*a1lcuts* (1ist cel 1 )) 

(equations '()) 

(*extra-equations* '())) 

((null *cuts*) (nreverse (append *ext.ra~equat ions* equations))) 

(let ((cut (pop *cuts*))) 

(push (list (ce11-goodname cut) (tree-form-chase cut shallow t)) 
equations)))) 

(defun tree-forni-chase (cell shallow top) 

(requ ire-cell cell) 

(let ((s (cel 1-true-supplier cell))) 

(cond ((and shallow (node-boundp cell)) (cell-value cell)) 

((and (not top) (not {singlenummarkp s))) 

(cond ((and (null (cell-owner s)) 

(not (null (cell-rule s)))) 

(do ((c (node-cells s) (cdr c))) 

((null c) (cel 1-contents s)) 

(cond ((good-global (car c) s) 

(cond ((not (memq (car c) *al lcuts*)) 

(push (car c) *allcuts*) 

(push (list (cell-naine (car c)) (cel 1-contents 
♦extra-equations*))) 

(return (cell-name (car c))))))) 

(t (let ((best (do ((c (node-cel 1 s' s) (cdr c))) 

((null c) s) 

(and (good-global (car c) s) 


(return (car c)))))) 

(cond ((and (not (and (eq best s) (globalp s))) 

(not (memq best *allcuts*))) 

(push best *allcuts*) 

(push best *cuts*))) 

(cell-goodname best))))) 

((cell-owner s) 

(cond ((and (eq s cell) (not top)) (cel 1-goodname s)) 

(t (let ((args (forarray (v (con-values (cell-owner s))) 

(cond ((eq v s) ,n /») 

((and (node-boundp s) 

(not (member (cell-name v) 

(rule-triggers 

(cel 1 -rule s))))) 

'?) 

(t (tree-form-chase v shallow ())))))) 
(nconc (list (ctype-symbol (con-ctype (cell-owner s)))) 

(if (eq (car args) '%) (cdr args) args) 

(and (con-info (cell-owner s)) 

(list (con-info (cell-owner s))))))))) 
((globalp s) (cell-name s)) ;??? 

(t (cel 1-contents s))))) 

Tabu; 6-59. Constructing the Traced-oul Algebraic Expression. 


s)) 
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(defun good-global (c s) ;is c a good global for naming s? 

(and (not (eq c s)) 

(globalp c) 

(or (and (or (eq (cell-state s) ©king) 

(eq (cell-state s) ©puppet) 

(eq (cell-state s) ©slave) 

(eq (cell-state s) ©friend)) 

(eq (cell-state c) ©slave)) 

(and (eq (cell-state s) ©rebel) 

(eq (cell-state c) ©dupe) 

(eq (cel 1-contents c) s)) 

(and (eq (cell-state s) ©dupe) 

(eq (cell-state c) ©dupe) 

(eq (cel 1-contents c) (cel 1-contents s)))))) 

(defun tree-form-unmark (cell) 

(require-cell cell) 

(let ((s (ce11 -true-supplier cell))) 

(cond ((nummarkp s) 

(unnummark s) 

(and (cell-owner s) 

(doarray (pin (con-values (cell-owner s))) 

(tree-form-umnark pin))))))) 

Table 6-60. Checking for a Good Global Name, and Unmarking, for tree-form. 


The new version of tree-form-chase ( fable 6-59) uses the % convention—as it translates 
the pins of some constraint, it notes which one was the output pin and substitutes a % for it. Also, 
for any pin that was not a trigger of the rule that computed the value, if any, it substitutes a ?, as 
before. When constructing the final form, if the first argument expression is % it is omitted. 

The predicate good-gl obal ( Table 6-60) takes a two cells of a node, and is true if the first 
is thought to be a good choice as a name for the second. For this to be the case it must be different 
from the second, must be the cell for a global variable, and must take its value from the same place 
the second one docs. (It might seem that the clause (eq (cel 1-state c) ©slave) ought 
rather to be 

(or (eq (cell-state c) ©slave) 

(eq (cell-state c) ©friend)) 

—however, a global variable never has its own value, and so can never be a friend.) 

The function tree-form-unmark runs around as before, resetting all the marks. 

As an example of what, consider this interaction: 

(test) ;set up temperature conversion network 

DONE 

(== fahrenheit (parameter -40)) 

DONE 
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(what centigrade) 

;The value -40 in CENTIGRADE was computed in this way: 

; CENTIGRADE «- (* (* (+ FAHRENHEIT % 32) 5) 9 %) 

; FAHRENHEIT «- -40 
OKAY? 

This algebraic form may be unfamiliar, but it correctly conveys the network structure used to 
compute the value. 

(== fahrenheit (default 32)) 

;;; These are the premises that seem to be at fault: 

; <CELL-415 (DEFAULT-413) [OPPOSED] KING 32>, 

; <CELL-412 (PARAMETER-410) REBEL -40 AGAINST 32> == FAHRENHEIT. 

;;; Choose one of these to retract and RETURN it. 

;BKPT Choose Culprit 

(return fahrenheit) ;uniquely identifies the culprit 

DONE 

Note that returning fahrenheit uniquely identifies the culprit even though it and both premises 
are all in the same node (cf. §6.3.20 and fable 6-27 (page 243)). It could also have been specified by 
(return parameter-410) . 

(what centigrade) 

;The value 0 in CENTIGRADE was computed in this way: 

; CENTIGRADE <-(*(* (+ FAHRENHEIT % 32) ?) 9 %) 

; FAHRENHEIT «- 32 
OKAY? 

Because 32 and sum to fahrenheit (which is also 32), therefore is zero, and so the 
other operand to the inner multiplication was not a trigger for the product. This other operand is 
therefore represented as a 


6.4. The New Improved Example 

One advantage of using the queue-based control structure is that pending computations arc 
stored explicitly as data structures rather than implicitly in the host-language control stack, which 
in many cases is of a finite size much smaller than the heap area—this is the case for many I ISP 
implementations, including Lisp Machine LISP. Using the system of Part One, it was not possible to 
run the N queens problem for N — 6 because the LISP system stack would overflow. There is no 
problem with the current queue-based system, however. 

The new language has the disallow construct, which allows cycling though a set of pos¬ 
sibilities. In this example we will obtain all four solutions for the six queens problem. At each step 
we will ask for the statistics also. 
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(sixqueen) ;start up the six queens problem 

DONE ;after much computation! 


The I ISP function s i xqueen merely creates a large number of constraints analogous to those 
in fable 5-19 (page 166), Table 5-20 (page 166), Table 5-21 (page 167), and fable 5-22 (page 167). 


(list qO 

ql q2 

q3 q4 

q5 ) 

(<CELL-49 

(QO) 

SLAVE 

i> 

<CELL-51 

(Ql) 

SLAVE 

3> 

< C E L L - 5 3 

(Q2) 

SLAVE 

5> 

<CELL-55 

(Q3) 

SLAVE 

0> 

<CELL-57 

(Q4) 

SLAVE 

2> 

<CELL-59 

(Q5) 

SLAVE 

4>) 



(stats) 

; 248 

; 248 

; 0 

; 81 

; 3895 

; 3742 

; 3156 

I 51 

; 535 

; 3495 

; 2785 

; 1291 

I 0 

; 143 

; 30 

; 124 

; 103 

I 0 

; 21 

; 124 


Repositories generated 
Cells generated 
Initialized cel 1 s 
Constraints generated 

Iterations of top-1evel-1oop queue scan 

Rules enqueued 

Added rules enqueued 

Forget rules enqueued 

Nogood rules enqueued 

Attempts to run a rule 

Successfully run rules 

Rule runs which dismissed 

Rules which overrode other rules 

Rules which superseded other rules 

Usurpations 

Contradictions dequeued for processing 
©NODE contradictions dequeued for processing 
©CONSTRAINT contradictions dequeued for processing 
©RESOLUTION contradictions dequeued for processing 
Contradictions actually processed 
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; 124 = Nogood culprits automatically chosen 

; 124 = Nogood sets installed 

; 201 = Number of calls to == 

12547 = Awakenings 
; 2546 = 0ADDED awakenings 

; 0 = 0FORGET awakenings 

; 9336 = 6N0G00D awakenings 

; 1270 = Values forgotten 

; 3778 = Number of nogood sets checked 

; 5706 = Number of nogood set pairs checked 

NIL 


There have been 103 ordinary contradictions and 21 resolutions. Now we will disallow this 
particular solution, and force a search for another. 

(disallow qO ql q2 q3 q4 q5) 

DONE 

(list qO ql q2 q3 q4 q5) 

(<CELL-49 (QO) SLAVE 3> 

<CELL-51 (Ql) SLAVE 0> 

<CELL-53 (Q2) SLAVE 4> 

<CELL-55 (Q3) SLAVE 1> 

<CELL-57 (Q4) SLAVE 5> 

<CELL-59 (Q5) SLAVE 2>) 



(stats) 

; 248 = Repositories generated 

; 248 = Cells generated 

; 0 = Initialized cells 

; 81 = Constraints generated 

; 5294 = Iterations of top-1evel -1oop queue scan 

; 5278 = Rules enqueued 

; 4318 = Added rules enqueued 

; 51 = Forget rules enqueued 

; 909 = Nogood rules enqueued 
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; 4847 = Attempts to run a rule 

; 4046 = Successfully run rules 

; 1800 = Rule runs which dismissed 

; 0 = Rules which overrode other rules 

; 267 = Rules which superseded other rules 

; 30 = Usurpations 

; 170 = Contradictions dequeued for processing 

; 128 = ©NODE contradictions dequeued for processing 

; 0 = ©CONSTRAINT contradictions dequeued for processing 

; 42 = ©RESOLUTION contradictions dequeued for processing 

; 170 = Contradictions actually processed 

; 170 = Nogood culprits automatically chosen 

; 170 = Nogood sets installed 

; 201 = Number of calls to == 

; 20332 = Awakenings 

; 3483 = ©ADDED awakenings 

; 0 = ©FORGET awakenings 

; 15764 = ©NOGOOD awakenings 

; 1898 = Values forgotten 

; 8913 = Number of nogood sets checked 

; 13603 = Number of nogood set pairs checked 

NIL 

(disallow qO ql q2 q3 q4 q5) 

DONE 

(list qO ql q2 q3 q4 q5) 

(<CELL-49 (Q0) SLAVE 4> 

<CELL-51 (Ql) SLAVE 2> 

CCELL-53 (Q2) SLAVE 0> 

<CELL-55 (Q3) SLAVE 5> 

<CELL-57 (Q4) SLAVE 3> 

<CELL-59 (Q5) SLAVE 1>) 



(stats) 

; 248 = Repositories generated 
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248 = Cells generated 
0 = Initialized cel 1 s 


; 81 = Constraints generated 

; 7159 = Iterations of top-level-loop queue scan 

; 7404 = Rules enqueued 

; 5876 = Added rules enqueued 

; 51 = Forget rules enqueued 

; 1477 = Nogood rules enqueued 

; 6652 = Attempts to run a rule 

; 5733 = Successfully run rules 

; 2469 = Rule runs which dismissed 

; 0 = Rules which overrode other rules 

; 428 = Rules which superseded other rules 

; 30 = Usurpations 

; 229 = Contradictions dequeued for processing 

; 159 = ©NODE contradictions dequeued for processing 

; 0 = ©CONSTRAINT contradictions dequeued for processing 

; 70 = ©RESOLUTION contradictions dequeued for processing 

; 229 = Contradictions actually processed 

; 229 = Nogood culprits automatically chosen 

; 229 = Nogood sets installed 

; 201 = Number of calls to == 

; 31887 = Awakenings 

; 4707 = ©ADDED awakenings 

; 0 = ©FORGET awakenings 

; 25468 = ©NOGOOD awakenings 

; 2755 - Values forgotten 

; 17166 = Number of nogood sets checked 

; 26378 = Number of nogood set pairs checked 

NIL 


(disallow qO ql q2 q3 q4 q5) 


DONE 
(list qO 

ql q2 

q3 q4 

q5 ) 

(<CELL-49 

(00) 

SLAVE 

2> 

<CELL-51 

(Ql) 

SLAVE 

5> 

<CELL-53 

(02) 

SLAVE 

1> 

<CELL-55 

(03) 

SLAVE 

4> 

<CELL-57 

(04) 

SLAVE 

0> 

CCELL-59 

(05) 

SLAVE 

3>) 
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(stats) 

; 248 = Repositories generated 

; 248 = Cells generated 

; 0 = Initialized cells 

; 81 = Constraints generated 

; 8991 = Iterations of top-1evel-loop queue scan 

: 9523 = Rules enqueued 

; 7321 = Added rules enqueued 

; 51 = Forget rules enqueued 

; 2151 = Nogood rules enqueued 

; 8427 = Attempts to run a rule 

; 7466 = Successfully run rules 

; 3123 = Rule runs which dismissed 

; 0 = Rules which overrode other rules 

; 660 = Rules which superseded other rules 

; 30 = Usurpations 

; 285 = Contradictions dequeued for processing 

; 172 = ©NODE contradictions dequeued for processing 

; 0 = ©CONSTRAINT contradictions dequeued for processing 

; 113 = ©RESOLUTION contradictions dequeued for processing 

; 285 = Contradictions actually processed 

; 285 = Nogood culprits automatically chosen 

; 285 = Nogood sets installed 

; 201 = Number of calls to == 

; 45184 = Awakenings 

; 5870 = @ADDED awakenings 

; 0 = 0FORGET awakenings 

; 36872 = ©NOGOOD awakenings 

; 3602 = Values forgotten 

; 32911 = Number of nogood sets checked 

; 51809 = Number of nogood set pairs checked 

NIL 


At tliis point all possible solutions have been generated. Disallowing this one causes a “hard¬ 
core contradiction”, after which the final statistics are as follows. 
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(stats) 

; 248 
; 248 
; 0 
; 81 
; 21387 
; 29538 
; 18027 
; 51 
; 11460 
; 20283 
; 19256 
; 8606 
; 0 
; 763 
; 30 
; 825 
; 197 
; 0 
; 628 
; 825 
; 824 
; 824 
; 201 
; 218830 
; 16150 
; 0 
; 190396 
; 9887 
; 162765 
; 250279 
NIL 


Repositories generated 

Cells generated 

Initialized cel 1s 

Constraints generated 

Iterations of top-1level-1oop queue scan 

Rules enqueued 

Added rules enqueued 

Forget rules enqueued 

Nogood rules enqueued 

Attempts to run a rule 

Successfully run rules 

Rule runs which dismissed 

Rules which overrode other rules 

Rules which superseded other rules 

Usurpations 

Contradictions dequeued for processing 
©NODE contradictions dequeued for processing 
©CONSTRAINT contradictions dequeued for processing 
©RESOLUTION contradictions dequeued for processing 
Contradictions actually processed 
Nogood culprits automatically chosen 
Nogood sets installed 
Number of calls to == 

Awakenings 

©ADDED awakenings 

©FORGET awakenings 

©NOGOOD awakenings 

Values forgotten 

Number of nogood sets checked 

Number of nogood set pairs checked 


It is useful to compare this to the results of the lisp program of'fable 5-18 (page 162), which 
uses chronological backtracking. 

(queens 6) 

Solution: (1,3,5,0,2,4) after 140 contradictions and 25 backtracks. 

Solution: (2,5,1,4,0,3) after 334 contradictions and 64 backtracks. 

Solution: (3,0,4,1,5,2) after 408 contradictions and 79 backtracks. 

Solution: (4,2,0,5,3,1) after 602 contradictions and 118 backtracks. 

Total of 742 contradictions and 149 backtracks. 

DONE 


The “backtracks” of this program correspond to resolution steps, and so we may compare 
numbers directly: 
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LISP 

Constraint 

LISP 

Constraint 


Contradictions 

Contradictions 

Backtracks 

Resolutions 

After first Solution 

140 

103 

25 

21 

After second Solution 

334 

128 

64 

42 

After third Solution 

408 

159 

79 

70 

After fourth Solution 

602 

172 

118 

113 

After exhaustion 

742 

197 

149 

628 


It easy to see that the non-chronological (eonstraint) version examines many fewer positions 
before arriving at a new solution. I he number of resolution steps is about the same, unless there 
arc no more solutions, in which ease it must do about the same amount of work as the chronologi¬ 
cal version to prove that there is no solution (this is not surprising). 


6.5. The New Improved Summary 

This chapter has presented a complete re-implementation of the constraint language developed 
in Part One. A few new features (such as disallow) have been added to the language, but the 
primary emphasis has been placed on speed. The new system records multiple reasons for believing 
a value. It uses a task queue control structure for more flexibility in allocating computational 
resources. It pre-compiles tables of rules for primitive operators for fast run-time access and dis¬ 
crimination of rule to be executed. It hashes constant cells in order to share those with the same 
value among multiple uses. It uses a uniform algebraic notation in printing pails of the network as 
expressions. 



Oh, once the opposition 
Was completully opposed 
To all the suppositions 
That was gen’rally supposed: 

An' now the superstitions 
That were tho't to be imposed 

Are seen by composition Chapter Seven 

To be slightly decomposed! 

-Walt Kelly (1952) 

/ Go Togo 

Correctness 


T ill* constraintsysti-m described in die previous chapter is a large program, sufficiently 
complicated that there may well remain in it subtle errors. Nevertheless, the design is 
intended to make it simple(r) to argue that it is correct. All of the program state is made explicit in 
the form of LISP data structures, concerning which certain strong invariants may be suited. 

I have not in any sense demonstrated that the system is correct. The system is an exercise in 
engineering; it is too large to be a reasonably manageable exercise in mathematics. However, in this 
chapter is outlined a series of statements which, if rigorously proved invariant over the processing 
of any queued task, would go a long way toward proving total correctness of the system. Some of 
these I have proved informally for certain classes of tasks, and consideration of these statements 
certainly aided in “cycballing” the code for errors. 

Parenthetical remarks provide definitions of terms and supplementary elucidation. 


7.1. The Structure of Nodes 

For every cell: 

• its id is a LISP symbol (read-only). (ITie remark “(read-only)” about a component means that the 
component may never be altered once initialized.) 

• its repository is (a pointer to) 1 a repository. 

L As in LISP everything is represented in terms of pointers, following this one reminder I shall not mention the 
presence of pointers. Nevertheless, the sharing of objects is very important! 
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• its owner is either () or a constraint (read-only). 

• its name is a LISP symbol or an integer (read-only). 

• its slate is one of the six constants ©king, ©puppet, ©friend, ©slave, ©rebel, ©dupe. 
(When we say “a cell is a king” we mean that its slate is ©king, and similarly for the others.) 

• its contents is either () , an integer, or a cell. 

• its rule is cither () or a rule. 

• its equivs is a list of distinct cells. (By “a list of distinct tilings” we mean “a list of things in which 
no thing appears more than once”. The list thus represents a set, and so the list may contain the 
elements in any order unless otherwise stated.) 

• its link is a cell or () . 

• its mark is (). (Thought apparently constant, this is not read-only! It may be used temporarily, 
but must always be reset to () before scheduling a new task.) 

For every repository: 

• its cells is a list of distinct cells. 

• its supplier is a cell. 

• its id is a LISP symbol (read-only). 

• its nogoods is a list of buckets; each bucket is a pair whose car is an integer and whose edr is a 
list of nogood sets. No two buckets in the nogoods of a single repository may contain the same 
integer. (We shall say that “a nogood set is in the nogoods of a repository” if the nogood set is a 
member of some list which is the edr of some bucket of the no goods of the repository.) 

• its contra is an integer. 

Relationships among cells and repositories; 

• For every repository r, for every cell c in the cells of r, the repository of c is r. 

• For every repository r, its supplier is a member of its cells list. 

• The lisp value of the id of a repository is that repository. 

• The lisp value of the id of a cell is that cell. 

• If the name of a cell is a symbol, the LISP value of that symbol is the cell. 

• The link of a cel! is a member of die cells list of the repository of that cell. 

• If a cell has a constraint for its owner, then its name is an integer. 

• The members of the equivs list of a cell are all members of the cells list of the repository of that 
cell. 

• If cell a is a member of the equivs Ust of cell b, then b is a member of the equivs of a. 

• No cell is in its own equivs list. 

• The cell which is the supplier of a repository must have () for its link. 

• Any cell which is not the supplier of its repository must have a cell for its link . 
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• If cell a is the link of cell b , then a is in the equivs list of b (and therefore b is also in the equivs 
list of a). 

• Consider the relationship between two cells a and b “cell b is the link of cell a"', the transitive 
closure of this relationship is an irrefiexivc partial order, that is, there arc no cycles. (This plus 
the fact that precisely one cell of a node has a null link implies that the link structure forms a 
directed tree with all paths eventually converging at the supplier.) 

Relationships among the states of cells and other tilings: 

<* No cell which is not a supplier is a king or puppet. 

• The cell which is the supplier for a repository is a king or puppet. (By “the supplier of a cell” we 
mean the supplier of the repository of the cell. By “the king of a cell” we mean the supplier of the 
repository of the cell, which is known to be a king.) 

• flic supplier of a rebel, friend, rebel, or dupe is a king. (Conversely, if the supplier of a 
repository is a puppet, then all other members of that repository’s cells list are slaves.) 

• A slave or puppet has () for its contents and its rule. 

• A dupe has a cell for its contents , and that cell is a rebel and a member of the cells list of the 
dupe’s repository. A dupe has () for its rule. 

• A king, friend, or rebel cell has an integer for its contents , and a rule for its rule. 

• The contents of a friend is the same as the contents of its king. 

• The contents of a rebel is different from the contents of its king. 

• A king, friend, or rebel cell either has a constraint for its owner, or has one of the three special 
rules *constant-rule*, *defaul t-rule*, or *parame ter-rule* for its nde. 

® The contra of a repository is equal to the number of rebels in its cells list. 

We say that “a cell has a value” if the cell is a king, friend, rebel, or dupe, or if it is a slave and 

the supplier of the cell's repository is a king, 'fhe value of a king, friend, or rebel is its contents', the 

value of a dupe is the contents of its contents (a rebel); the value of a slave which has a value is the 

contents of its king. 


7.2. Constraint-types and Constraints 

For every constraint-type: 

• its name is a 1 ISP symbol (read-only). 

• its vars is an array of distinct I ISP symbols (read-only). (When a constraint-type is being dis¬ 
cussed, a reference to N refers to the length of this array. An integer used to index this array, or 
any parallel array, is called a pin-number. The corresponding clement of the vars array is called 
the pin-name for that pin-number.) 
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• its added-rules is an array of length N of lists of distinct rules (read-only). 

• its forget- rules is an array of length N of lists of distinct rules (read-only). 

• its nogood-rules is an array of length N of lists of distinct rules (read-only). (The three arrays 
added-rules, forget-wles, and nogood-rules of a constraint type are called the “rule arrays” of the 
constraint-type. The set of all rules appearing in any element of any rule array of a constraint- 
type is called the “rule set” for that constraint-type.) 

• its symbol is a I ISP symbol (read-only). 

Hvery constraint-type is entirely read-only. 

For every constraint: 

• its name is a LISP symbol (read-only). 

• its clype is a constraint-type (read-only). (When a constraint is being discussed, a reference to N 
refers to the length of the vars array of the clype of the constraint. Also, by an “instance” of a 
constraint-type we mean any constraint whose ctype is that constraint-type.) 

• its values is an array of length N of distinct cells (read-only). (The set of cells which are elements 
of the values array of a constraint are called the “pins” of that constraint.) 

• its info may be anything (normally read-only). 

• its queued-rules is an integer. 

Miscellaneous relationships: 

• The i isp value of the name of a constraint-type is that constraint-type. 

• flic l ISP value of the name of a constraint is that constraint. 

• 'Hie symbol of a constraint-type has on its property list a ctypename property whose value is 
the name of the constraint-type. 

• If a cell has a constraint for its owner, then the name of the cell is an integer j not less than 0 and 

less than N, and entry / of the values array of the owner of the cell is that cell. (It follows that 

all the cells in the values array of a constraint have distinct name components ranging from 0 to 
N— 1.) 


7.3. Rules 

For every rule: 

• its triggers is a list of distinct integers (read-only). 

• its oulvar is cither () or an integer (read-only). 

• its code is a LISP symbol (read-only). 

• its ctype is a constraint-type (read-only). 
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• its bits is an integer 0, 1, 2, or 3 (read-only). (We say that a rule is a &nogood rule if this 
integer is 1 or 3, and a &nogoodbeg rule if it is 2 or 3.) 

• its id-bit is a positive integer which is a power of two (read-only). 

Every rule is entirely read-only. 

Relationships among rule components: 

• The LISP value of the code of a rule is that rule. 

• flic LISP function definition for die code of a rule is a lisp function of one argument. The value 
of this function (when given an appropriate argument, to be described later) is cither an integer 
or one of the special constants Qlose and ©dismiss, and it may not be an integer if the 
oulvar of the rule is (). 

• If the oulvar of a rule is an integer, Uicn it is not equal to any member of the triggers list. 

• If the oulvar of a rule is () then the bits of the rule is zero. 

Relationships between rules and constraint-types: 

• If a rule is a member of any element of any rule array of a constraint-type, dien the ctype of diat 
rule is that constraint-type. 

• The integer elements of the triggers of a rule, as well as die oulvar of the rule if it is not (), are 

each not less than 0 and less than N, the length of the rare of the ctype of the rule. (Thus each of 

diesc integers is a pin-number.) 

• A rule is a member of element j of the added-rules array of its ctype if and only if j is a member 
of the rule’s triggers. 

• A rule is a member of element j of the forget-rules array of its ctype if and only if its oulvar is j. 

• A rule is a member of element j of the nogood-rules array of its ctype if and only if its oulvar is j 
and its bits is non-zero. 

• The id-bit components of all the rules of a constraint-type’s rule set are distinct. 

On the running of rules: 

• The code of a rule may be applied only to an instance of die ctype of the rule. (When such an 
application is performed we say that the rule is “run” on the instance constraint.) 

• When a rule is run on a constraint, the trigger cells for die rule must all have values. (By the 
“trigger cells” of a rule being run, we mean the set of cells which are elements of the values of 
the array and whose names (which are the corresponding indices into diat array) arc members of 
die /riggers list of the rule.) 

• The result computed by running a rule on a constraint may depend only on the values of the 
trigger cells and the info of the constraint; and also on the nogoods of the repository of the 
output cell (if any) provided that die bits of die rule is non-zero. (If the rule’s oulvar is not () 
and the result of running the rule on a constraint is an integer, we say that “the rule produced 
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the integer for the output cell”, where by “output cel!” we mean that clement of the values array 
of the constraint whose index in the array equals the oulvar of the Rile.) 

• If a cell is a king, friend, or rebel, and its owner is a constraint, then its mle must be a rule in 
the rule set of the ctype of the owner of the cell, and that rule’s oulvar must be equal to the name 
(an integer) of the cell. Moreover, the triggers cells of the rule must all have values which would 
cause the rule, if run, to return the integer which is the contents of the cell. (Very important! 
This requirement implies that all values are well-founded upon premises.) 

On the consistency of rules: 

• Suppose that two rules in the rule set of some constraint-type have the same integer / for their 
respective oulvar components, and that the set of elements of die triggers of the first is a subset 
(not necessarily a propert subset) of the set of elements of the triggers of the second. Consider 
some instance of that constraint-type, and suppose that every pin which is a trigger cell of the 
second rule (and therefore also of the first) has a value. Consider the values which would be 
produced by running either of the two rules in this same situation. If both values would be 
integers, then they must be the same integer unless at least one of the rules is a &nogoodbeg 
Rile. (Indeed, in this situation one would expect the first rule, which gets less information, to be 
a &nogoodbeg rule.) 

• Consider a constraint, and an ordered sequence with distinct elements (n, r 2 ,..., r n ) of at least 
two rules from the rule set of the ctype of the constraint. Suppose each of the rules has a non¬ 
null oulvar, and that for each 1 < j < n the output pin of rule r 3 is a trigger cell for rule 
r j+ \, and the output pin of rule r n is a trigger cell for rule r { . Suppose that all the trigger 
cells of all the rules have values, except those which arc output pins of all rules except r n . Now 
suppose that the code of rule is run, producing a value which is then assigned to the output 
pin of r ; then rule r 2 is run, and so on. Then the value produced by r n must agree in value 
with the value its output pin already had unless some r ] is a &nogoodbeg rule. (Example: 
one adder rule takes a and b and computes c; then if the rule that takes b and c to produce 
a were mn, it ought to produce the same value for a. Note, however, that such a rule would 
not ordinarily actually be run (Riles are not awakened by values computed by other rules of the 
same constraint), precisely because this consistency is taken for granted.) 


7.4. Tasks and Queues 

Properties of tasks and queues: 

• A queue contains, among other things, a bag of Risks. Queues arc of two kinds: rule queues and 
contradiction queues. (1 am ignoring the * rebel -queue* here, for that is a minor variation.) 
Rule queues may contain only Rile tasks, and contradiction rules only contradiction tasks. 
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• A rule task is a pair of a rule and a constraint. The constraint must be an instance of the ctype of 
the rule. 

• Contradiction tasks arc lists, and arc of three kinds, distinguished by a special constant in the car 
of the list. A @node contradiction task has two cells in its cadr and caddr. A ©constraint 
contradiction has a constraint for its cadr , and its eddr is an a-list associating cells with integers. 
A ©resolution contradiction has a edr which is an a-list associating cells with integers. 

• At “task scheduling time”, any task may be removed from any queue and executed. When that 
task has completed, it is task scheduling time again. (It is at tins time that all of the invariants 
presented in this chapter must hold.) 

Rule tasks: 

• Consider any rule and any instance of that rule’s ctype. Suppose that all the triggers cells for that 
rule have values. Then one of three situations must hold: (1) At least one of the trigger cells is 
a king, friend, or rebel (implying that its value was computed by some other rule for the same 
constraint). (2) A task pairing the rule with the constraint is in some rule queue. (3) Let x be 
the result of running the code of the rule on the constraint in that situation. If x is ©lose then 
there must be a ©constraint task on the contradiction queue mentioning the all trigger cells 
of the rule. If x is an integer then the output pin of the rule must be a king, friend, or rebel, and 
have that integer as its contents. 

• If the value q for a constraint’s queued-rules satisfies (q (mod 2 J +')) > 2 j for some integer j 
(i.e. die 2 J -bit is set in the bit-vector represented by q ), then there is in some rule queue a rule 
task pairing that constraint with the unique rule in the rule set of the constraint’s ctype which 
has an id-bit component equal to V. 

Contradiction tasks: 

• For every rebel cell there must be in some contradiction queue a ©node contradiction task 
mentioning the rebel cell and its king. 


7.5. Nogood Sets 

• A nogood set is a list whose car is the lisp symbol nogood and whose edr is an a-list associating 
distinct repositories with integers. 

• A nogood set is in the nogoods of a repository if and only if the repository is mentioned in the 
a-list of the nogood set. More specifically, the nogood set will be in that (unique) bucket of the 
repository’s nogoods whose car is the integer which the nogood set’s a-list associates with the 
repository. 

• If a nogood set exists, then it must be the case that if all values were removed from the network, 
excepting constant cells, and then default cells containing the integers specified in the nogood 
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set were added to the respective repositories, then by running appropriate rules a contradiction 
could be derived whose premises would be precisely the added default cells. (This invariant is 
stated very loosely, of course. The point is that a contradiction could be logically derived in a 
well-founded manner solely from the values in the nogood set.) 


7.6. User Interface 

Invariants of the previous sections are concerned with the internal workings of the system. 
There also need to be statements relating these internal workings to what the user types, to ensure 
that the work done by the system actually reflects the meaning understood by the user. 

• Whenever a task is to be scheduled, it is permissible instead to process a user request (which 
may of course alter the network). 

• If there are no tasks on any of the queues (in which case we say that the system is quiescent ), 
then the network is free of contradiction, and the stated relationships hold among all quantities 
in the network, flic network structure may then be understood to represent the sum total of all 
preceding user input, and the contents of cells to represent validly deduced values. 

• A sequence of user inputs (other than information queries such as why) can be understood in 
terms of an equivalent sequence of inputs consisting only of create, variable, ==, and 
disallow statements, in that order. 

The remainder of this section would consist essentially of the language definition from §6.1, 
which is therefore not repeated here. 


7.7. Summary 

This chapter docs not by any means indicate all the invariants which might possibly be stated. 
It does present a large number of invariants, some of them rather complex, which ought to be 
shown to hold. 

One would also like to be able to exhibit a true multiprocessing implementation of a constraint 
language. If it were based on this implementation, one approach would be to identify the precise 
conditions under which two tasks could interfere with each other, and then arrange interlocks so 
that interfering Risks cannot run in parallel. Of course, the current implementation enforces such 
an interlock, a rather stringent one requiring that no two tasks run in parallel! But, for example, 
it is entirely plausible that many rule tasks could run in parallel, provided that they operated on 
constraints sufficiently separated within the network, or that appropriate interlocks were placed 
in process-setc with regard to the setting of cell contents and recording of nogood sets. 
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(Techniques for proving properties of parallel programs of this type are described in [Owieki 1975] 
and [Grics 1977].) 
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Part Three 


Abstraction 



Well, then Fido got up off the floor 
And he rolled over 

And he looked me straight in the eye. 

And you know what he said? 

"Once upon a time 
Somebody say to me." 

(This is the dog talkin' now.) 

"What is your 

conceptual 

continuity? 

"Well. I told him right then." Fido said. 

"It should be easy to see 
The crux of the biscuit 
Is the apostrophe." 

Well, you know, the man who was talkin' to the dog 
looked at the dog and he said 
(Sort of starin' in disbelief), 

"You can't say that!" 

He said, 

"It doesn’t! 

And you can't! 

/ won't! 

And it don't! 

It hasn't! 

It isn't! 

It even ain't! 

And it shouldn't! 

It couldn't!" 

He told me, "No no no!" 

/ told him, "Yes yes yes!" 

/ said, ‘7 do it all the time!" 

(Ain’t this boogie a mess?) 

—Frank Zappa (1974) 
“Stinkfoot” 
Apostrophe 
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"The Old Oaken Bucket" 

Already is written: 

There's naught left to me 
For an amphibrach fitten. 

—Guy Lewis Steele, Sr. 

A stitch in time is worth two in the bush 

If you count them before you come to them , Chapter Eight 

Excepting February, which has twenty-eight. 

—The Reverend Doctor Cuddles 

Hierarchy 


P reviously presented VERSIONS of the constraint language have been “flat”. In this chap¬ 
ter two forms of hierarchy are introduced. One stems from a macro-definition mechanism, 
which allows the user to define non-primitive constraint devices in terms of a network of other 
constraints. One may think of this as a trivial kind of subroutine mechanism, one which does not 
permit recursion. This mechanism introduces a calling hierarchy or an abstraction hierarchy, with 
complex things defined in terms of simpler things to many levels. The other form of hierarchy 
stems from permitting the user to write expressions in the nested algebraic syntax described in 
§6.2.5; this is a syntactic hierarchy, with complex expressions built from simpler ones. Both forms 
of hierarchy allow networks to be expressed much more concisely. 


8.1. New Features for the Constraint Language 

Here the changes to the constraint language arc described. Besides the expression syntax 
and the macro mechanism, a special parsing and evaluating mechanism will be introduced which 
will relieve the restriction of the syntax to LlSR-evaluablc forms. The parser takes an S-exprcssion 
representing a request for the constraint system, and reduces it to a set of simple statements. The 
evaluator acts on these statements, usually just by calling the LISP evaluator (since much of the 
system is derived from the version in Chapter Six), but not always. In addition, a simple iteration 
construct is provided. 
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8.1.1. The User Can Describe Networks Using the Expression Syntax 

All nested expressions are considered to be abbreviations for a collection of create and = = 
statement (indeed, in the implementation described later in this chapter, expressions arc processed 
by constructing that equivalent collection and then processing the collection). The syntax will 
therefore be explained as such abbreviations. 

Suppose that sym is the symbol for some constraint-type named type, and that the names of 
the pins for that constraint-type are x, y, z,...; then the expression 

((sym name) a b c ...) 

is a statement equivalent to these statements: 

(create name type) 

(== a (the x name)) 

(== b (the y name)) 

(== c (the z name)) 


Also, if any one of the argument forms is the symbol then the expression is not a statement, but 
rather denotes the corresponding pin of the constraint instance. Thus, for example, 

(== ((sym name) a % c ...) foo) 

is equivalent to 

(create name type) 

(== a (the x name)) 

(== c (the z name)) 

(-= (the y name) foo) 

because the % was in the position corresponding to (the y name). 

There must be exactly as many argument forms as there arc pins for the specified constraint- 
type (with two exceptions), and they are matched by order of appearance of argument forms in the 
mentioning expression and order of appearance of pin-names in the declaration of the constraint- 
type. If no argument form is %, then the expression is a statement and docs not denote anything; 
if one if %, then the expression denotes the corresponding pin. No more than one argument form 
may be a 36. 
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One exception to the rule is that one fewer argument form than the number of pins may be 
written, and no % written; in this case a % is taken to be an implicit argument form preceding all 
the others. The other exception is that an extra argument form may be written, which will become 
the info component of the constraint instance. In this way one can write (assumption % 4), or 
simply (assumption 4). The special routine assume is not needed in the implementation to 
construct an assumption; the necessary machinery falls out of this general notation. 

As an example, a temperature conversion network may be described by the single statement 

((+ add) fahrenheit ((* othermult) ((* mult) 9 centigrade) 5 %) 32) 

which is entirely equivalent to the old definition 

(create add adder) 

(create mult multiplier) 

(create othermult multiplier) 

(== fahrenheit (the c add)) 

(== (the b add) (constant 32.)) 

(== (the a add) (the a othermult)) 

(== (the c othermult) (the c mult)) 

( = = (the b othermult) (constant 5)) 

(== centigrade (the b mult)) 

( = = (the a mult) (constant 9)) 

(Note that the variable declarations have been omitted. The parser arranges to perform an 
implicit variable declaration during the parsing process for any variable mentioned in an ex¬ 
pression, provided that the variable has not already been so declared. To get the effect of re- 
declaring a variable, the user can just destroy it and then mention it again.) 

If instead of a list ( sym name) in the “operator position” of an expression, the user writes 
simply name, then the parser generates a name of the form type - nnn. 

If in place of an argument form the user writes “?”, then no == statement is generated for 
that argument position; it means “the corresponding pin is not connected to anything here”. 


8.1.2. The User Can Define Non-primitive Constraints 

A form is provided for declaring new constraints in terms of old ones: 

(defcon name pin-names . body) 

says that name is the name of a new constraint-type whose vars is the set of names pin-names. 
Whenever an instance of name is to be created, a copy of the network described by the statements 
in body is constructed. Thereafter name may be used as any other constraint-type name in create 
statements. 
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Figure 8-1. User Definition of the i f Device. 


As an example, we can define a “temperature converter device” which has two pins called f 
and c which enforces the Fahrenhcit-to-Ccntigradc relationship between the two pins: 

(defcon temp-converter (f c) 

((+ add) f ((* othermult) ((* mult) 9 c) 5 %) 32)) 

If later we were to say ((temp-converter tc) fahrenheit centigrade) then the 
usual relationship between fahrenheit and centigrade would hold, mediated by an in¬ 
stance of teinp-conve rte r called tc. 

One can of course refer to the pins of such a constraint instance by saying, for example, 
(the c tc) to refer to the pin c of tc. One can also refer to the devices used in the 
instantiated network. The expression (the add tc) refers to the adder of the network for 
the instance tc of temp-converter; it follows that (the b (the add tc)) is a pin 
which is connected to the constant 5. If tc had been part of another device zed then 
(the b (the add (the tc zed))) would name a pin. In this way we can use pathnames to 
refer to parts of parts of... parts of a complex constraint device. 

As another example of a useful device, we can define an i f device, a non-directional version 
if the standard if-then-clse-fi programming-language construct (which connects a “result” pin to 
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one of two “source” pins; or, from another point of view, connects a source pin to one of two result 
pins!): 

(defcon if (result test then else) 

(gate test then result) 

(gate (+ 1 test %) else result)) 

(Sec Figure 8-1.) This definition uses an adder to perform logical negation. With this, one can then 
write things like 

(+ f (* (* 9 (if kelvin-flag (+ c % 273) c)) 5 %) 32) 

to enable c to be cither a temperature Kelvin or a temperature centigrade according the the flag 
kelvin-f1ag. 

If any variables other than pins arc mentioned in the body of a defcon definition, they 
are taken to be local to the definition; the variable is instantiated afresh for each instance of the 
containing definition. If it is desired that every instance be hooked up to some single instance of a 
global variable, then the construct (global var) may be used to refer to it. 


8.1.3. Pathnames May be Written is Abbreviated Form 

A pathname such as (the b (the add (the tc zed))) may be contracted to simply 
(the b add tc zed). For even greater conciseness, it may be written simply as zed. tc . add . b. 
Flerc die path is written in die reverse order, with the name of the original object first and succes¬ 
sive selectors following, separated by periods. If the name contains a leading period, dicn the 
name of the initial object is global; thus . f oo is the same as (global f oo). This is of course 
similar to the component selection notation of many programming languages, and also to the file 
pathnames of Multics and UNIX, which use characters other than the period. 

This facility is made possible by the introduction of the parser, which checks symbols in the 
input for periods in their names, and expands them into appropriate the and global constructs. 


8.1.4. The vector Construct Provides Limited Iteration 
The special form 

((vector name) size interface common . body) 

defines and instantiates a special kind of constraint-type, a vector consisting of size copies of the 
network defined by body, placed side by side. The size must be an integer—this limited facility docs 
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not allow for variable-length vectors. Flic instances of body have names which arc the integers from 
zero (inclusive) to size (exclusive). 1 

The interface describes how adjacent networks in the series arc connected. It is a list of 
descriptors, and each descriptor is a list of four things: 

( leftedge left right rightedge) 

The left and right must be names; they are pin-names for the body. If two instances x and y of 
the body are adjacent, with x to the left of y, then the right of * is connected to the left of;'. The 
instance of body at the left end of the row has its left connected to left edge, which may be any 
expression denoting a cell, or ?; similarly for the right of the instance at the right end of the row 
and rightedge. 

The list common is a list of names global to the vector construct which are to be made 
available to every instance of body. (T his set is dcduciblc from context, but to simplify the present 
implementation the user is required to declare these.) 

As usual, if one writes (vector ...) instead of ((vector name) ...) then a name is 
automatically generated. 

Figure 8-2 shows a diagram representing the body of a vector defined as 
((vector foo) 7 ((a p x i) (b q y j) (c r z k)) (f g h) <body>) 


I For technical reasons (he names are actually LISP symbols whose print names are digit strings which look like 
the way the integer would print, thus the first instance in a vector has the name |0| or /0, not 0, to use Lisp 
Machine LISP syntax. As we shall sec, when pathnames with periods are used this distinction is not apparent. 
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Figure 8-3 shows three of the seven instances of the body belonging to the vector, and their connec¬ 
tions. The left-hand pins p, q, and r of each one are connected to the right-hand pins x, y, and 

z of the instance to the left. The leftmost instance has its left-hand pins connected to a. b, and c, 

while the rightmost has its right-hand pins connected to i, j, and k. All of them have the common 
pins f, g, and h connected to the external variables of the same name. 

As a simple concrete example: 

((vector foo) 4 ((input a b output)) () (+ b a a)) 

makes a length-four chain of adders like the one in Figure 3-2 (page 84). This statement is entirely 
equivalent to these declarations: 

(DEFCON VECTOR-BODY-374 (A B) (+ B A A)) 

(DEFCON VECTOR-TYPE-373 (A B) 

((VECTOR-BODY-374 |0|) A ?) 

((VECTOR-BODY-374 |1|) (THE B |0|) ?) 

((VECTOR-BODY-374 |2|) (THE B jlj) ?) 

((VECTOR-BODY-374 j 3 j) (THE B |2|) B)) 

((VECTOR-TYPE-373 FOO) INPUT OUTPUT) 

The body of the vector is made into a macro-constraint-type. Another macro-constraint-typc is 
declared for the entire vector, which makes four instances of the body and makes the internal 
connections between adjacent instances. Finally, this latter macro-constraint-type is instantiated, 
the instance is named foo, and the edge connections to input and output arc made. Note the 
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(deftype constraint-type 

(ctype-name ctype-vars ctype-added-rules ctype-forget-rules 
ctype-nogood-rules ctype-symbol (ctype-initfn ())) 

(format stream "<Constraint-type ~S>" (ctype-name constraint-type))) 

(deftype constraint 

(con-name con-owner con-ctype con-values con-info (con-queued-rules 0)) 

(format stream ".~}:~S>" 

(con-pathname constraint) (ctype-name (con-ctype constraint)))) 

(deftype macro-constraint-type 

(mctype-name mctype-pins mctype-al1vars mctype-creations mctype-connector) 

(format stream ”<Macro-constraint-type ~S>” (mctype-name macro-constraint-type))) 

(deftype macro-constraint 

(mcon-name mcon-owner mcon-mctype mcon-values mcon-devices) 

(format stream "<~{~A~f.:~S>" 

(con-pathname macro-constraint) 

(mctype-name (mcon-mctype macro-constraint)))) 

Compare this with Table 6-3 (page 204). 

Tablk 8-1. Macro-constrnint-types and Macro-constraints. 


use of ? to indicate no connection, and the “numerical” names for the components of the vector. 
For example, there is an equating between foo. 0 . a and foo. a, which is in turn connected to 
input. Similarly, foo.O.b and foo.l.a are connected, as are foo.l.b and foo. 2. a. 


8.2. Implementation of Parsing and Macros 

The code given here shows only the changes from the full system described in Chapter Six. 
First the new data types are described, then changes to previously existing mechanisms, and finally 
the new top-level loop and parser. 


8.2.1. Macro-constraints Arc Instances of Macro-constraint-typcs 

User-defined macro-constraints are represented in a way very similar to ordinary constraints, 
fable 8-1 gives the data structure definitions for constraint-types and macro-constraint-types, for 
constraints and macro-constraints. The differences arise from the fact that a constraint has pins and 
rules, but a macro-constraint has a defining network. The interface information is similar, however. 

The list (actually an array) of pins vars in a constraint-type becomes two in a macro-constraint- 
type: pins and allvars , the first being a subset of the second. The allvars is the set of all variables in 
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the defining network, while pins is die set of terminals, variables to which the “outside world” con¬ 
nects. Primitive constraints have no internal variables represented by cells, and so do not require an 
allvars set. 

A macro-constraint-type docs not have a symbol because in this simple implementation there 
is no means for printing a macro-constraint in algebraic form. It does not have tables of rules, for 
dierc arc no rules. It does have, however, two components called creations and connector. 'Hie 
creations is a list of 3-lists; each 3-list describes one create operation to be performed when in¬ 
stantiating the network for an instance of the macro-constraint-type. The first element of such a 3- 
list is the name of the device; die second is the type (either a constraint-type or a macro-constraint- 
type) of the device; and the diird is a datum to be installed in the info component of the device (if 
it is a primitive constraint). The connector is a function of one argument which, when applied to a 
macro-constraint instance, will make all the cquatings necessary to wire up the network. 

A constraint as well as a cell may now have an owner , which of course must be a macro¬ 
constraint. The owner of a cell may now be a constraint or a macro-constraint. 
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(deftype cell (cell-id cel 1-repository cell-owner cell-name 

(cel 1-contents {)) (cell-state @lose) (cell-rule ()) 

(cell-equivs '()) (cell-link ()) (cell-mark ())) 

| (progn (format stream "<~S (~{~A~t,~})" (cell-id cell) (cel 1-pathname cell)) 
(select (cell-state cell) 

((Spuppet) (format stream " PUPPET)")) 

((Qslave) (format stream " SLAVE”0[ ~S”]>" 

(select (cell-state (node-supplier cell)) 

((©king) (node-value cell)) 

((Qpuppet) ()) 

(otherwise 

(list 'bad-supplier 

(cell-state (node-supplier cell))))))) 
((©king) (format stream "~@[~* [OPPOSED]”] KING ~S>" 

(piusp (node-contra cell)) 

(cell-value cell))) 

((©friend) (format stream "”@[~* [OPPOSED]”] FRIEND ~S>" 

(piusp (node-contra cell)) 

(cell-value cell))) 

((©rebel) (format stream " REBEL ~S AGAINST ~S>" 

(cell-value cell) 

(if (eq (cell-state (node-supplier cell)) ©king) 

(node-value cell) 

(list ' bad-supplier 

(cell-state (node-supplier cell)))))) 
((©dupe) (format stream " DUPE ~S AGAINST ~S>" 

(cell -value cel 1) 

(if (eq (cell-state (node-supplier cell)) ©king) 

(node-value cel 1) 

(list 'bad-supplier 

(cell-state (node-supplier cell)))))) 
(otherwise (format stream " BAD STATE ~S>" (cell-state cell)))))) 

Compare this with T able 6-4 (page 206). 

Table. 8-2. Now Priming Formal for Cells. 


Note the user of the function con-pathname in the printing code for constraints and 
macro-constraint. Phis causes a constraint to print like this: 

<TC.ADD:ADDER> 

which is the add device (an adder) of macro-constraint tc. Similarly, the printing format for 
cells is changed (Table 8-2) to something like: 

<CELL-78 (TC.ADD.B) PUPPET> 

for the b pin of that same adder. 

The construction of pathnames is shown in Table 8-3. All that is necessary is to start from a 
given object and trace up the hierarchy of owners. The resulting pathname is a list of names, with 
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(defun cell-pathname (cell) 

(require-cel 1 cell) 

(cond ((null (cell-owner cell)) (list (cell-name cell))) 

((constraint-p (cell-owner cell)) 

(nconc (con-pathname (cell-owner cell)) 

(list (aref (ctype-vars (con-ctype (cell-owner cell))) 

(cell -name cell))))) 

((macro-constraint-p (cell-owner cell)) 

(nconc (con-pathname (cell-owner cell)) 

(list (aref (mctype-allvars (mcon-mctype (cell-owner cell))) 

(cell -name cell))))) 

(t (lose "Had cell owner ~S for ~S.” (cell-owner cell) (cell-id cell))))) 

(defun con-pathname (con) 

(cond ((constraint-p con) 

(con-pathname-1 (con-owner con) (con-name con))) 

((macro-constraint-p con) 

(con-pathname-1 (mcon-owner con) (mcon-name con))) 

(t (lose "Not a constraint: ~S" con)))) 

(defun con-pathname-1 (owner name) 

(cond ((null owner) (list name)) 

(t (requ ire-macro-constraint owner) 

(nconc (con-pathname owner) 

(list (car (aref (mctype-creations (mcon-mctype owner)) 

name))))))) 

Tabu- 8-3. Construction of Pathnames for Cells and Devices. 


(defun ce11-goodname (cell) 

(require-cel 1 cell) 

(cond ((globalp cell) (cell-name cell)) 

((or (eq (cell-rule cell) *constant-rule*) 

(eq (cell-rule cell) *default-rule*) 

(eq (cell-rule cell) *parameter-rule*)) 

(list (cell-name cell) (cel 1-contents cell))) 

(t (cons 'the (cel 1-pathname cell))))) 

Compare this with Table 6-53 (page 280). 

Tabi.e 8-4. The Best Name for a Pin Is Its Pathname. 


8-4). 


Hie function cel 1 - goodname can be simplified by letting it use cel 1 - pathname (Table 







320 Chap h r Eight 


Hihrarchy 


8.2.2. Owners Can Now Be Constraints or Macro-constraints 

There arc many places in the code which check for owners of cells, and which formerly re¬ 
quired such owners to be constraints. Now an owner can be a constraint or a macro-constraint. 
Error checks must be modified to permit either kind of owner. Rather than reprinting many lines of 
code just to show these simple modification, I will just describe the changes here. 

Functions which used to require constraints and now must permit either constraints or macro¬ 
constraints: gen-cell, Tabic 6-6 (page 211). 

Functions which tested the owner of a cell and assumed a non-null owner to be a constraint, 
and which must now test that it is in fact a constraint (rather than a macro-constraint): awaken. 
Table 6-28 (page 245); why(in the case that the cell has no value). Table 6-52 (page 279); 
why-how(it now tests that the owner is a constraint purely for error-checking purposes), fable 
6-53 (page 280); fast-expunge-nogoods-markand fast-expunge-nogoods-umnark, 
fable 6-40 (page 264); desi red-premi ses-cons t rai ntand desi red-premi ses-unmark, 
fable 6-55 (page 283); tree-form-trace(in the progn form), fable 6-57 (page 285); 
tree-form-deep. Table 6-58 (page 286); and tree-form-unmark, fable 6-60 (page 288). 

Also, there is one change in tree-form-chase ( fable 6-59 (page 287)), near the middle of 
the code: 


((cell-owner s) 

(cond ((and (eq s cell) (not top)) (cel 1 -goodname s)) 
••• ) 


becomes 


((cell-owner s) 

(cond ((or (and (eq s cell) (not top)) 

(macro-constraint-p (cell-owner s))) 
(cel 1-goodname s)) 

... ) 


the effect being that if the chase comes to a cell owned by a macro-constraint then it must be a 
puppet, an artificial supplier, and so the chase may as well end there. 
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|(defmacro create (name type &optional (info ())) ‘(^create ',name ,type ,info)) 

|(defun *create (name type info) 

(prog2 (^destroy name) 

(gen-constraint type name () info) 

(run?))) 


(defmacro destroy (symbol) ‘(^destroy symbol)) 

J(defun ^destroy (symbol &optional (forced ())) 

(require-symbol symbol) 

(and (boundp symbol) 

(let ((val (symeval symbol))) 

(cond ((cell-p val) 

(cond ((and (globalp val) (eq (cell-name val) symbol)) 
(*detach val) 

(makunbound (cell-id val)) 

(makunbound symbol)) 

(t (lose "Illegal re-declaration of ~S." symbol)))) 
((constraint-p val) 

| (cond ((or forced (eq (con-name val) symbol)) 

(forarray (p (con-values val)) (*detach p)) 
(makunbound symbol)) 

(t (lose "Illegal re-declaration of ~S.” symbol)))) 
((macro-constraint-p val) 

(cond ((or forced (eq (mcon-name val) symbol)) 

(forarray (p (mcon-values val)) (*detach p)) 
(forarray (d (mcon-devices val)) (^destroy d t)) 
(makunbound symbol)) 

(t (lose "Illegal re-declaration of ~S." symbol)))) 
((or (constra int-type-p val) 

I (macro-constraint-type-p val) 

(repository-p val) 

(rule-p val)) 

(lose "Illegal re-declaration of ~S." symbol)) 

(t (makunbound symbol))))) 

' done) 

Compare this with Tabic 6-11 (page 217) and Table 6-41 (page 265). 

Table 8-5. Creating and Destroying Things. 


8.2.3. Macro-constraints Can Be Created and Destroyed 

'Hie create form, which specifics a name for a constraint and the constraint-type to instan¬ 
tiate, now permits a third argument form to be supplied ( fable 8-5). 'This third form, if present, is 
used to fill in the info component of a constraint. 

The routine *dest roy has been modified to be able to destroy macro-constraints, and not to 
destroy macro-constraint-types. Also, the new argument forced is a flag which forces constraints 
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and macro-constraints to be destroyed despite the error-check that their names be symbols; this is 
needed in order to recursively destroy sub-devices of a macro-constraint. 
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|( def un 

gen-constr 

aint (ctype name &optional (owner ()) (info 

())) 


(stat 

istic gen- 

constraint) 



1 (and 

owner (reg 

uire-macro-constraint owner)) 



(if owner (requ 

ire-integer name) (require-symbol name)) 



J (cond 

((constra 

int-type-p ctype) 




(let ((c 

(make-constraint))) 




(or owner (set name c)) 




(setf 

(con-name c) name) 




(setf 

(con-ctype c) ctype) 




(setf 

(con-owner c) owner) 




(setf 

(con-values c) 





(array-of (fortimes (j (array-length (ctype- 

vars ctype))) 



(gen-cell j c)))) 




(setf 

(con-info c) 





(if (ctype-initfn ctype) 





(funcall (ctype-initfn ctype) c info) 





info)) 




(doarr 

ay (bucket (ctype-forget-rules ctype)) 




(dot 

ist (rule bucket) 




(a 

nd (null (rule-triggers rule)) 





(enqueue-rule rule c ©forget)))) 




c)) 





((macro-constraint-type-p ctype) 




(let ((c 

(make-macro-constraint))) 




(or owner (set name c)) 




(setf 

(mcon-name c) name) 




(setf 

(meon-metype c) ctype) 




(setf 

(mcon-owner c) owner) 




(setf 

(mcon-values c) 





(array-of (fortimes (j (array-length (metype 

-allvars ctype))) 



(gen-cell j c)))) 




(setf 

(mcon-devices c) 





(array-of (fortimes (j (array-1 ength (metype 

-creati 

ons ctype))) 



(let ((x (aref (mctype-creations 

ctype) 

j))) 



(gen-constraint (cadr x) j c ( 

caddr x 

)))))) 


(f tinea 

11 (mctype-connector ctype) c) 




c)) 





(t (1ose 

"~S not a constraint-type or macro-constrain 

t-type. 

" ctype)))) 

Compare 

this with Table 6-11 (page 217). 





Table 8-6. Generating a Constraint or Macro-constraint. 



The function gen-constraint, which is used by create, is now capable of instantiating 
cither a constraint-type or a inacro-constraint-typc. Moreover, an instance may have an owner now 
(which must be a macro-constraint), and if so the name will be an integer rather than a symbol. 

When a macro-constraint-type is instantiated, a macro-constraint is created and its name, 
metype , and owner slots arc filled in. Then a cell is generated for every variable of the macro¬ 
constraint, as determined by the allvars array of the metype, and these arc stored in a corresponding 
array in the values component. Next all the devices needed by the defining network are created 
(this will involve recursive calls to gen-constraint); these are stored in the devices array. 
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(defmacro the (x y) ‘(*the ',x ,y)) 

J(defmacro my (x) ‘(the ,x *me*)) 

(defun *the (name con) 

(or (cond ((constra int-p con) (lookup name con)) 

((macro-constraint-p con) (macro-lookup name con)) 

(t (lose "Not a constraint: ~S." con))) 

(lose "~S has no part named ~S." con name))) 

(dofun lookup (name thing) 

(require-constraint thing) 

(let ((names (ctype-vars (con-ctype thing))) 

(cells (con-values thing))) 

(let ((n (array-length names))) 

(do ((j 0 <+ j 1))) 

((= j n) ()) 

(and (eq (aref names j) name) (return (aref cells j))))))) 

(defun macro-lookup (name thing) 

(require-macro-constraint thing) 

(let ((names (metype a 11vars (meon-metype thing))) 

(cells (mcon-values thing))) 

(let ((n (array-1 ength names))) 

(do ((j 0 (+ j 1))) 

((= j ") 

(let ((creations (metype-creations (meon-metype thing))) 
(devices (mcon-devices thing))) 

(let ((m (array-length creations))) 

(do ((k 0 (+ k 1))) 

((= k m ) 0) 

(and (eq (car (aref creations k)) name) 

(return (aref devices k))))))) 

(and (eq (aref names j) name) (return (aref cells j))))))) 

Compare this with Table 6-32 (page 253). 

Tabi.f. 8-7. Looking Up Parts of a Macro-Constraint. 


Finally, the connector function is applied to the macro-constraint instance in order to wire up the 
network. 


8.2.4. 


The the construction must now be able to locate named parts of either constraints or macro¬ 
constraints. The function *the now merely divides into two cases; for macro-constraints it calls 
macro-lookup, which searches first the names array and then the creations array of the 
macro-constraint-typc. When a matching name is found, the corresponding clement of the values 
or devices array of the macro-constraint is returned. 

The my macro is included as a convenience; “my x” is the same as “the x of *me*”. (See 
Table 8-7.) 
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(defconst 6quit (list '@quit.)) ;quit from consys loop 

(defconst ©nothing (list '©nothing)) something the consys loop won't print 

(defun consys () 

(let ((rubout-handler ()) variables controlling the 

(read-preserve-delimiters ())) ; Lisp Machine RLAD function 

(format t "~&;Welcome to The Constraint System.") 

(consys-loop "]:"))) 

(defun consys-loop (prompt) 

(do () (()) ;do forever (until explicit return) 

(format t prompt) 

(setq - (si:read-for-top-level)) 

(and (eq - ©quit) (return)) 

(setq // (multiple-value-list (evaluate-input -))) 

(setq *** **) 

(setq ** *) 

(setq * (car //)) ;save first value 

(dolist (value //) 

(cond ((not (eq value Soothing)) 

(terpri) 

(funcall (or prinl #'prinl) value)))) 

(setq +++ ++) 

(setq ++ +) 

(setq + -))) 

Table 8-8. The Top-Level "Read-Hval-Prinl" Loop for liie Constraint System. 


8.2.5. A “Rcad-Kval-Print” Loop Processes User Requests 

We have discussed all the changes to previously existing code; these had primarily to do with 
the introduction of macro-constraints. The all-new code to be discussed has primarily to do with 
the newly introduced surface syntax. It includes a top-level processing loop and a parser. The 
loop is responsible for reading user input, parsing and evaluating it, printing any results, and then 
iterating. Parsing occurs in two stages: the LISP function read reads in a string of characters and 
produces a lisp S-cxpression, which is then further processed by the parser to be presented here. 

The top-level loop is shown in 1’able 8-8. It is typical of LISP interaction loops, and uses the 
MACLISP/Lisp Machine lisp conventions for “interaction variables”. The variable + always holds 
the last thing typed in by the user, and ++ and +++ the two things before that. The variable - 
has the expression being processed. The variable // has a list of all the values returned as a rsult 
of evaluating the last expression, and * has die first of these values, ** and *** bcign earlier 
instances of *. These variables are purely for user convenience, so that he can refer to partial 
results without losing them if he forgot to set some variable to the computed value. 
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The important thing about this loop is that it handles the user interaction, prompting, reading, 
processing, and printing. The two constants @quit and ^nothing provide special control. One 
causes the loop to terminate, reverting to the lisp system; the other is a “magic value” that will 
not be printed. This allows a request such as == or why to print nothing, rather than DONE 
or Q. E .D. (which some users find annoying). Though those trivial changes arc not shown here, 
functions such as why should in fact be altered to return @noth i ng after printing a message. 
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(defun evaluate-input (input) 

(cond ((or (atom input) (eq (car input) 'the)) 

(eval (parse-thing input))) 

((and (symbolp (car input)) (get (car input) 'request)) 
(eval (cons (car input) 

(forlist (x (cdr input)) (parse-thing x))))) 
((eq (car input) 'defcon) (define-macro input)) 

((eq (car input) 'destroy) 

(dolist (x (cdr input)) (^destroy x))) 

((eq (car input) 'lisp) (eval (cadr input))) 

(t (multiple-value-bind (creations equations definitions) 
(parse-statements (list input) () ()) 

(dolist (stmt creations) (eval stmt)) 

(dolist (stmt equations) (eval stmt))) 

@noth ing ))) 

(dolist (x '(stats reset-stats variable queue-stats reset-queues 
run? disallow change retract forget dissolve detach 
disconnect disequate why why-ultimately what)) 
(putprop x t 'request)) 

Tablh 8*9. Discrimination of input Forms. 


8.2.6. User Input Forms Are Divided into Three Categories 

Flic top-level loop calls eval uate-- input (Table 8-9) to process the user input. This func¬ 
tion categorizes the input form as a statement (a create, = = , or vector form), a request, or a 
descriptor for a thing (which at the top level is interpreted as a request for the value of that thing). 
Atoms and the-forms arc things. A list whose first element is a symbol with a non-null request 
property is a request (note the definitions of such properties by the dolist form in Table 8- 
9); such requests are assumed to take “things” as their arguments. The defcon and destroy 
requests arc handled specially, because they take tilings other than “things” as arguments. A list 
whose first clement is lisp is an escape, so that lisp expressions can be evaluated easily from 
within the consys loop; this is a special user convenience, not strictly speaking part of the 
supported constraint language. Any other form is Liken to be a statement. 


8.2.7. Defining a Macro Generates a Macro-Constraint-Type 

The function def ine-macro parses a defcon request of the form described in §8.1.2. 
After the pieces of the form have been picked out and checked, two “environment” structures are 
created, one for cells and one for constraints. Rach environment is a list cell whose cdr is an a-list 
(the a-list for devices is initially empty). The car is not used for anything; the use of a header cell 
allows new entries to be added by using a side-effect. Bach a-list pair consists of a name and a flag; 
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(defun define-macro (input) 

(let ((name (if (atom (cadr input)) (cadr input) (caadr input))) 

(symbol (if (atom (cadr input)) (cadr input) (cadadr input))) 

(pins (caddr input)) 

(body (cdddr input))) 

(require-symbol name) 

(require-symbol symbol) 

(let ((conenv (list 'conenv)) 

(cellenv (cons 'cellenv (forlist (p pins) (require-symbol p) (list p))))) 
(multiple-value-bind (creations equations definitions) 

(parse-statements body cellenv conenv) 

(gen-macro-constraint-type name 

symbol 

pins 

(forlist (x (cdr cellenv)) (car x)) 

creations 

equations))))) 

Table 8-10. Processing a Macro Definition. 


in conenv the flag indicates whether a create for that device has been encountered yet, and in 
cellenv the flag is unused. (The environments have the same structure so that common routines 
can process them.) Initially all the pin names are in cel 1 env. 

The body of a macro definition should be a list of statements, and these arc parsed in the 
given environments. (The parsing process may alter the environment structures.) The statement 
parsing produces three results: a list of create forms, a list of == forms, and a list of defcon 
forms (which result only from vector forms, and can be ignored (as they arc here) because they 
are processed when generated). The creations and equations, along with all the names now in 
cellenv arc passed to gen-macro-constrain-type. 
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(defun gen-macro-constraint-type (name symbol pins allvars creations equations) 

(require-symbol name) 

(*destroy name) 

(let ((ct (make-macro-constraint-type))) 

(set name ct) 

(putprop symbol name 'ctypename) 

(setf (metype-name ct) name) 

(setf (metype-pins ct) (array-of pins)) 

(setf (mctype-alIvars ct) (array-of allvars)) 

(setf (mctype-creations ct) 

(array-of (forlist (c creations) 

(or (eq (car c) 'create) 

(lose "Mon-creation ~S for GEN-MACRO-COMSTHAI NT-TYPE." c)) 
(or (and (boundp (caddr c)) 

(or (constraint-type-p (symeval (caddr c))) 

(macro-constraint-type-p (symeval (caddr c))))) 
(lose "Not a defined constraint-type ~S." (caddr c))) 

(list (cadr c) (symeval (caddr c)) (cadddr c))))) 

(let ((codename (gen-name name 'connector))) 

(setf (metype-connector ct) codename) 

(fset codename ‘(named-lambda ,codename (*me*) 

(let ((*run-flag* ())) 

,©equal ions 
(run?)))) 

(compile codename)) 
ct)) 


Table, 8-11. Generating a Macro-Constraint-Type. 


This function (Tabic 8-11) generates a macro-constraint-type data structure. The name , pins , 
and allvars slots arc filled in. The list of creations is pre-processed, in that the keyword create 
is removed, and the name of the type to be instantiated is replaced by the data structure for the 
type itself, which must be a constraint-type or a macro-constraint-type. Finally, the connector 
function is constructed from the list of equations. These equations will all refer to a local vari¬ 
able x as “(my x)”, using the my macro of Table 8-7, so all that is needed is to execute these 
equations where the I ISP variable *me* is defined. Also, the * run-flag* is bound to () 
to prevent propagation from occurring until the whole network is wired, to avoid wasted effort. 
Once a lambda-expression (actually a Lisp Machine MSP “named-lambda” expression) has been 
constructed, it is assigned to the “function cell” of a generated LISP symbol, and then the comp i 1 e 
function is applied. The result is that the connector function is a compiled lisp function. (The call 
to comp i 1 e could be omitted, and everything would still work, only more slowly.) 
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(declare (special *inputs* *equations* ^creations* *definitions*)) 

(defun parse-statements (inputs cellenv conenv) 

(do ((^inputs* inputs) 

(♦equations* '()) 

(♦creations* '()) 

(*definitions* ' ())) 

((null *inputs*) 

(dolist (x (cdr conenv)) 

(or (cdr x) (format t "~&;Warning: constraint ~S not defined." (car x)))) 
(return *creations* *equations* *def initions*)) 

(let ((stmt (pop *inputs*))) 

(cond ((atom stmt) (lose "Internal error: atomic statement's." stmt)) 

((eq (car stmt) ' = =) 

(let ((things (forlist (z (cdr stmt)) 

(parse-thing z cellenv conenv ())))) 

(do ((th things (cdr th))) 

((null th)) 

(dolist (x (cdr th)) (push ‘(== ,(car th) ,x) *equations*))))) 
((eq (car stmt) 'create) 

(push stmt *creations*) 

(and conenv 

(let ((slot (assq (cadr stmt) (cdr conenv)))) 

(cond ((null slot) (push (cons (cadr stmt) t) (cdr conenv))) 
((null (cdr slot)) (rplacd slot t)) 

(t (lose ";Constraint ~S multiply created." 

(cadr stmt))))))) 

((eq (car stmt) 'vector) 

(parse-vector (gen-name 'vector) 

(cadr stmt) (caddr stmt) (cadddr stmt) (cddddr stmt))) 
((and (not (atom (car stmt))) (eq (caar stmt) 'vector)) 

(parse-vector (cadar stmt) 

(cadr stmt) (caddr stmt) (cadddr stmt) (cddddr stmt))) 
(t (parse-constraint stmt t)))))) 

Table 8-12. Parsing Statements. 


8.2.8. Statements Are Reduced to Simple Statements 

The function parse-statements ('lable 8-12) maintains a queue * inputs*, which is a 
queue of statements to be processed. The results will be a list of equations, a list of creations, and 
a list of (already processed) definitions (which is returned primarily so that parse-statements 
can be tested independently of the rest of the system and the results examined). 

The == statement is generalized so that more than two things can be equated; each thing is 
directly equated to every other thing (so that equating n things results in -l!tzl) binary equatings). 
The things arc all parsed using parse-thing. 
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A create statement is output to the *creations* list, and an entry is located or created 
in conenv if that environment is not null (the environments are null for top-level statements and 
non-null when parsing statements for a macro body). 
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(defun parse-constraint (form stmtp) 

(cond ((symboip (car form)) 

(parse-constraint-pins 

(car form) () (cdr form) stmtp)) 

((and (not (atom (car form))) 

(symboip (caar form)) 

(symboip (cadar form)) 

(null (cddar form))) 

(parse-constraint-pins 

(caar form) (cadar form) (cdr form) stmtp)) 

(t (lose "Unknown form: ~S." form)))) 

(defun parse-constraint-pins (ctypesym userconname arguments stmtp) 

(require-symbol ctypesym) 

(and userconname (require-symbol userconname)) 

(or stmtp (memq '% arguments) (push '% arguments)) 

(let ((ctypename (get ctypesym ' ctypename))) 

(or (and ctypename (symboip ctypename)) 

(lose "~S is not the symbol for any constraint-type." ctypesym)) 

(let. ((ctype (symeval ctypename)) 

(conname (or userconname (gen-name ctypename)))) 

(or (constraint-type-p ctype) 

(macro-constraint-type-p ctype) 

(lose "Unknown constraint type: ~S.” ctypename)) 

(let ((pinarray (if (constraint-type-p ctype) 

(ctype-vars ctype) 

(mctype-pins ctype)))) 

(let ((args (cond ((= (length arguments) (array-length pinarray)) arguments) 

((- (length arguments) (+ (array-length pinarray) 1)) 
(reverse (cdr (reverse arguments)))) 

(t (lose "Wrong number of arguments to ~S: ~S." 
ctypename arguments)))) 

(info (and (not (= (length arguments) (array-length pinarray))) 

(car (last arguments))))) 

(push ‘(create ,conname ,ctypename ,@(and info (list info))) *inputs*) 

(let ((result ())) 

(do ((j 0 (+ j 1)) 

(a args (cdr a))) 

((= j (array-1ength pinarray))) 

(cond ((eq (car a) '%) 

(cond (result 

(lose "Multiple %'s to ~S: ~S." ctypename arguments)) 
((not stmtp) 

(setq result ‘(the ,(aref pinarray j) ,conname))) 

(t (lose "Statement fed % to ~S: ~S." 
ctypename arguments)))) 

((not (eq (car a) '?)) 

(push ‘(== (the ,(aref pinarray j) ,conname) ,(car a)) 

♦ inputs*)))) 

result)))))) 

Table 8-13. Parsing an "Algebraic Expression”. 


Vectors are fanned out to parse-vector. All other forms arc assumed to be network 
descriptions expressed in the nested algebraic form. 
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The function parse-constraint (Table 8-13) determines whether or not the constraint 
to be generated has been given a name by the user. The function parse-constraint-pins 
deals with the details of the % and ? conventions, performs error checking, and then decomposes 
the form into equivalent create and == statements which are then enqueued on * inputs* 
for re-processing. The flag stmtp is true iff the given form is a statement (implying that no % is 
permitted), in which case () is returned. If stmtp is false, then the value is a name for the pin 
corresponding to the (explicit or implicit) occurrence of %. 
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(defun parse-thing (thing &optional (cellenv ()) (conenv ()) (simplep t)) 
(cond ((numberp thing) ‘(constant ,thing)) 

((symbolp thing) 

(parse-recursive-symbol (get-pname thing) cellenv conenv thing)) 
((atom thing) (lose "Unknown atomic thing: ~S." thing)) 

((and (memq (car thing) '(default parameter)) 

(fixp (cadr thing)) 

(null (cddr thing))) 
thing) 

((eq (car thing) 'global) 

(parse-global-symbol (cadr thing) t)) 

((and (eq (car thing) 'the) (cddr thing)) 

(parse-the (cdr thing) conenv)) 

((not simplep) 

(parse-thing (parse-constraint thing ()) cellenv conenv ())) 

(t (lose "Non-simple thing: ~S." thing)))) 

Table 8-14. Parsing a Reference to a Thing. 


(defun parse-recursive-symbol (pname cellenv conenv thing) 

(let ((pos (string-reverse search-char #/. pname))) 

(cond ((null pos) 

(parse-simple-symbol (or thing (intern pname)) 

(if thing cellenv conenv) 

(not (null thing)))) 

((zerop pos) 

(parse-global-symbol (intern (substring pname 1)) (not (null thing)))) 
(t ‘(the ,(intern (substring pname (+ pos 1))) 

, (parse-recursive-symbol 

(substring pname 0 pos) cellenv conenv ())))))) 

Tabu- 8-15. Parsing a Pathname Written with Periods. 


8.2.9. Pathnames with Periods Arc One of Many Forms of Reference 

The function parse-thing reduces a reference to a “thing” to either a simple variable 
name, a pathname, or a constant or similar form. A number is converted to a constant form, 
so that one may write (+ x 3 ) rather than (+ x (constant 3 )). Symbols arc examined for 
periods by parse-recursive-symbol. A default or parameter form stands as written. 
A global form refers to a global variable, and is given to process-global-symbol . A the 
form has its own processor. Anything else is regarded as a nested algebraic expression, which must 
have an explicit or implicit % in it; parse-constraint is used to parse that form and return 
the name of a pin, which is then (for generality) re-processed by parse-th ing. 
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(defun parse-simple-symbol (sym env cellp) 

(require-symbol sym) 

(cond ((null env) (parse-globa1-symbol sym cellp)) 

((assq sym (edr env)) ‘(my ,sym)) 

(t (push (list sym) (edr env)) ‘(my ,syin)))) 

Table 8-16. Parsing a "Simple" (Ha!) Symbol. 


Atomic symbols arc pulled apart by parse-recursive-symbol (Table 8-15). lfa“.” is 
found in the print name of the symbol, then the symbol is divided into two parts, the part before 
the last “. ” and the part after it. The part after is the selector for a the form, and the part before 
is recursively parsed. As an efficiency trick, thing is passed in, so that if the name contains no “. ” 
then the thing can be returned directly without the expense of a call to intern. Also, a leading 
indicates a global symbol, as discussed in §8.1.3. 

When not within a macro body, all symbols are global. Within a macro body, a simple symbol 
(not explicitly made global by a leading or use of the global form) is local, implying that 
it must be entered into the environment and that it should be referred to as “my” (that is, the 
macro’s) symbol. The function parse-simple-symbol (Table 8-16) performs these operations. 
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(defun parse-global-symbol (sym cellp) 

(require-symbol sym) 

(cond ((not (boundp sym)) 

(cond (cellp 

(putprop sym t 'special) -.compiler nonsense 

(set sym (gen-cell sym))))) 

((not cellp) 

(or (constraint-p (symeval sym)) 

(macro-constraint-p (symeval sym)) 

(format t ;Warning: ~S has a non-constraint value ~S." 
sym (symeval sym)))) 

(t (or (and (cellp (symeval sym)) 

(globalp (symeval sym))) 

(format t "~&;Warning: ~S has a non-cell value ~S." 
sym (symeval sym))))) 

sym) 

Table 8-17. Parsing a Global Symbol. 


(defun parse-tiie (list conenv) 

(if (nul1 (cdr list)) 

(parse-simple-symbol (car list) conenv ()) 

‘(the ,(car list) ,(parse-the (cdr list) conenv)))) 

Table 8-18. Parsing a the Expression. 

If a global symbol has no (USP) value, then a cell is automatically generated for it in 
parse-global-symbol (Table 8-17). This relieves the user of the constraint language from 
having to declare all his variables. If it does have a value, then it had better be the desired kind of 
object (a cell or a constraint, as determined by the Hag cellp). 

The only purpose of the function parse-the (Table 8-18) is to allow extended pathnames 
of the form (the a b c ...). This could just as easily have been put into the USP macro 
definition of the, but I thought it would be more appropriate to do it here, as part of the move 
away from dependence on the USP evaluator. 

8.2.10. Vectors Are Easily Defined in Terms of Macros 

The function parse-vector (Table 8-19) reduces a vector statement to equivalent state¬ 
ments and two macro-constraint-type definitions, one for the body and one for the vector of the 
body. The def ine-macro function of Table 8-10 is applied to the two definitions to cause the 
macro-constraint-typcs to exist immediately; unfortunately, this must be done before the other 
statements can even be parsed properly. An example of the results of processing a vector form 
appears in §8.1.4. 
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(defun parse-vector (vectornaine size interface common body) 

(require-integer size) 

(let ((vectortypename (gen-name 'vector-type)) 

(bodyname (gen-name 'vector-body)) 

(vectordev ices (fortimes (j size) (intern (format () "~D" j))))) 

(do ((x interface (edr x)) 

(lowpins '() (cons (cadar x) lowpins)) 

(highpins '() (cons (caddar x) highpins))) 

((null x) 

(let ((bodydef 

‘(defcon ,bodyname ,(append lowpins highpins common) ,@body)) 
(vectordef ‘ 

(defcon ,vectortypename ,(append lowpins highpins common) 

,@(do ((d vectordev ices (edr d)) 

(low lowpins (forlist (h highpins) ‘(the ,h ,(car d)))) 

(s '() (cons ‘((,bodyname ,(car d)) 

,91ow 

,@( if (edr d) 

(forlist (ignore highpins) '?) 
highpins) 

,©common) 

s))) 

((null d) (reverse s)))))) 

(define-macro bodydef) 

(define-macro vectordef) 

(push bodydef *definitions*) 

(push vectordef *definitions*)) 

(push ‘((,vectortypename ,vectorname) 

,@(forlist (x interface) (car x)) 

,@(forlist (x interface) (cadddr x)) 

,©common) 

* inputs* ))))) 

Tahlh 8-19. Parsing a vector Statement. 


8.3. Example of the Use of Macro-Constraints 

Here we will define a macro-constraint-typc which will constrain one number to be the ged 
of two others, using the formulation of §1.1.1. It will use a vector, the body of which performs one 
step in the simplified (using subtraction rather than division) Euclidean algorithm. We will start in 
the MSP system, and enter consys. 

(consys) 

;Welcome to The Constraint System. 

] : (defcon gcd7 (x y g) 

((vector v) 7 ((x qin qout endl) (y rin rout end2)) (g) 

(== rout qin) 
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(<! p qin rin) 

(gate p qout (+ rin qin %)) 

(gate (+ 1 p %) qout (+ qin rin %)) 

(gate (= qout 0) rout g))) 

<Macro-constraint-type GCD7> 

The “] : ” is the (rather silly-looking) prompt for user input to the constraint system. Our first 
input defines a macro-constraint-type gcd7 which constrains g to be the greatest common divisor 
of x and y provided that it can be found in seven substraction steps or fewer. (We will have more 
to say later about this arbitrary limitation!) It was certainly written with a functional view in mind, 
and so I shall describe it that way; but it is written in a constraint language, and so of course can 
“run backwards” to the extent permitted by its structure and the local propagation technique. 

An instance of gcd7 is a vector of seven steps. Kach step (sec Figure 8-4) has two pins on the 
left called qin and rin and two on the right called qout and rout (which connect to the qin 
and r i n of the next step to the right). In each stage, rout is equal to q i n, and qout is equal to 
either the difference between qin and rin or the difference between rin and qin. The value 
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of p determines which one is used; p is derived by comparing qin and rin in such a way that 
qout will be the positive difference. Finally, g is equal to rout if qout, is zero. It is easy to sec 
thethegedof qout and rout is the same as that of qin and rin, and that if qout is zero then 
rout must in fact be the gcd. 

The boundary conditions arc that the qin and rin of the leftmost stage are equated to x 
and y respectively. The variables endl and end2 could have been question marks; they arc not 
used for anything in particular, but using names will allow us to examine them. 

Now let us create an instance of gcd7 called f oo, and set x to 6 and y to 10. 

]:((gcd7 foo) 6 10 answer) 

]: answer 

<CELL-79 (ANSWER) SLAVE 2> 

Note that no result was printed for die creation of the instance (because the top-level loop saw 
the “magic value” ©nothing). The result answer is indeed 2. 

We can now look at various cells of the network and inspect their values. 

] : foo . endl 

<CELL-81 (F00.END1) SLAVE 2> 

] : foo.end2 

CCELL-83 (F00.END2) SLAVE 0> 

The two final values are 2 and 0, which is consistent with a gcd equal to 2. 

]:foo.v.0.qout 

<CELL-473 (FOO.V.O.QOUT) SLAVE 4> 

]:foo.v.1.qout 

<CELL-413 (FOO.V.l.QOUT) SLAVE 6> 

]:foo.v.2.qout 

<CELL-353 (FOO.V.2.QOUT) SLAVE 2> 

]:f oo.v.3.qout 

<CELL-293 (FOO.V.3.QOUT) SLAVE 4> 

]:f oo.v.4.qout 

<CELL-233 (FOO.V.4.QOUT) SLAVE 2> 

]:foo.v.5.qout 

<CELL-173 (FOO.V.5.QOUT) SLAVE 2> 

]:foo.v.6.qout 

<CELL-109 (FOO.V.6.QOUT) SLAVE 0> 

This is die sequence of intermediate values computed. (Compare diis with sequences in §1.1.1). 
Note how easily we can refer to parts of parts of a vector, using the pathname notation. (We can 
also examine constraints as well as cells: 

]:foo. v 

<F00.V:VECTOR-TYPE-65> 
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]:f 00.v . 4 

<F00.V.4:VECTOR-BODY-66> 

though that is not officially part of the language.) 

Now let us examine how the value for answe r was deduced. 

]:(why answer) 

;The value 2 is in ANSWER because it is connected to (THE F00 V |6| GATE-73 B) 
; and <F00 . V. 6 . GATE-73 : GATE> computed it by rule <B<-GATE-RULE-21( P, A)> 

; from: CELL-113 (P) = 1, CELL-115 (A) = 2. 

Again, no “return value” (Q.E.D.) is printed now because why returns ©nothing. The 
output could be cleaned up a little by changing cel 1 -goodname to return not a the-style 
pathname but a name with periods in it. 

]:(why-ultimately answer) 

;The value 2 is in ANSWER because it is connected to (THE F00 V |6| GATE-73 B) 
; and it was ultimately derived. 

(It says that it was “ultimately derived” because only constants were involved, and constants are 
now omitted from the set of premises for a deduction.) A number of connections were involved: 


These connections were involved: 
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ANSWER == (THE F00 G). 


Now let us get up the courage to ask what the entire computation was! (1 have taken the 
liberty of reformatting the output by inserting white space and line breaks.) 
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]:(what answer) 

;The value 2 in ANSWER was computed in this way: 

; ANSWER <- (GATE (= (GATE (+ 1 (<! (THE F00 V |5| GATE-68 A) 

(THE FOO V j 41 GATE-70 A)) 

%) 

% 


(+ (THE FOO V |5| GATE-68 A) 

(THE FOO V |4| GATE-70 A) 

%)) 

0 ) 

(THE FOO V ]5| GATE-68 A) 

%) 

(THE FOO V 141 GATE-70 A) <- 

(GATE (+ 1 (<! (THE FOO V j31 GATE-68 A) (THE FOO V |2| GATE-70 A)) %) 
% 


(+ (THE FOO V |3| GATE-68 A) (THE FOO V |2| GATE-70 A) %)) 

(THE FOO V 121 GATE-70 A) <- 

(GATE (+ 1 (<! (THE FOO V |1| GATE-68 A) (THE FOO V j 01 GATE-70 A)) %) 
% 

(+ (THE FOO V j1| GATE-68 A) (THE FOO V |0| GATE-70 A) %)) 

(THE FOO V 101 GATE-70 A) <- (GATE (+ 1 (<! 10 6) %) % (+ 10 6 %)) 

(THE FOO V j 1 j GATE-68 A) <- 

(GATE (<! (THE FOO V |0| GATE-70 A) 10) 

% 

(+ 10 (THE FOO V |0| GATE-70 A) %)) 

(THE FOO V 131 GATE-68 A) <- 

(GATE (<! (THE FOO V |2| GATE-70 A) (THE FOO V |1| GATE-68 A)) 

% 

(+ (THE FOO V |1| GATE-68 A) (THE FOO V |2| GATE-70 A) %)) 

(THE FOO V 151 GATE-68 A) <- 

(GATE (<! (THE FOO V |4| GATE-70 A) (THE FOO V |3| GATE-68 A)) 

% 


(+ (THE FOO V |3| GATE-68 A) (THE FOO V |4| GATE-70 A) %)) 


For all the use of “algebraic” notation, this is fairly hard to wade through! Part of the problem 
is that the explanation system doesn’t take advantage of the macro-call hierarchy to produce sum¬ 
mary explanations. One would like an explanation to go something like “The answer was computed 
by f oo . v . 6 from its q i n and r i n, which it got from f oo . v . 5, and so on, down to f oo . v . 0 
which got its inputs from f oo. x and f oo. y.” 


8.4. Discussion of the Macro Language 

In this chapter we have added to the constraint language an abstraction capability in the form 
of a simple macro mechanism, a limited iteration feature, and a front-end command processing 
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loop and parser to permit some useful syntactic abbreviations. 1 am pleased with the front end, 
for the most part, but the macro and iteration features are clearly deficient compared with what a 
useable constraint language requires. Here 1 discuss these deficiencies and possible solutions. 

Every time a macro-constraint-type is instantiated, a complete copy is made of the defining 
network structure. This is wasteful of space; it is as if every time a constraint-type were instantiated 
a copy were made of all the rules. Now certainly new cells must be created for each macro-instance, 
because they hold values that are different for each instance. The reason a complete copy must be 
made is that presently the connectivity information is also stored in the cells. Cells point at devices 
and other cells, which in turn point back, and these back-pointers therefore require individual 
copies of each device data structure. It ought to be possible to re-design the data structures in such 
a way that the macro-constraint-typc contains a single copy of the connectivity and device informa¬ 
tion as a full network with full back-pointers (presently that information is stored, but as directions 
for construction, not as a network). Then an instance would contain only an array of cells, which 
would determine their connectivity by referring to die “network template” in the macro-constraint- 
typc. This is entirely analogous to the situation with constraints and constraint-types. (Of course, 
this idea trades time for space in requiring indirection to the constant, shared template. Indeed, 
Borning seems to do something similar to this in thinglab [Burning 1979]. But such sharing may 
not be desirable in a multi-processor constraint language implementation.) 

A more important problem is that when a macro-constraint is created, all of its parts must first 
be fully instantiated (in the current implementation). This makes it impossible to write recursively 
defined constraints. One might like, for example, to write a factorial constraint: 

(defcon factorial (f n) 

(= p n 0) 

(gate p f 1) 

(+ 1 p notp) 

(factorial (gate notp f %) (+ (gate notp n %) % 1))) 

This cannot work in the current implementation because in the process of creating an instance of 
factorial another instance of factorial must be created, and so there is indefinite regress. 
This is a standard problem with any macro-type language. It is analogous to a programming lan¬ 
guage in which all procedure calls are replaced by the code for the called procedure (procedure 
integration) before any part of the program is run. What is needed is a way to instantiate a macro 
only partially, then compute using some of its parts, and then create the rest of its parts only 
when necessary. One possible heuristic is never to instantiate a sub-macro unless at least one argu¬ 
ment has propagated to the call to it (the assumption being that it won’t generate values without 
input—not always true when the assume construct is used!). This would allow the definition 
of factorial given above to operate properly. If one said (factorial answer 3), then 
one instance of factorial would be made, containing an equality test, a gate, an adder, and 
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so on, plus a dummy instance (a “procedure call') of factorial that lias not yet actually been 
created. The value 3 propagates from n, producing zero for p, and so f is not gated to 1, but 
instead n is gated to the second adder to calculate 3 — 1 = 2. This is then visible on a pin 
of the dummy instance, and so the recursive instance of factorial is created at this point to 
replace the dummy instance (and this actual instance itself now contains another dummy instance). 
After two more steps there are four actual instances of factorial nested, with the innermost 
containing yet another dummy instance. "This last one is not actually created, however, because n is 
zero and so the gates prevent any values from propagating to the pins of the dummy instance. 

I have constructed a constraint system that operates in this manner, and it has successfully 
run recursive constraint networks such as the definition of factorial given above. It is not 
of the same “lineage” as the systems presented here, however, but an offshoot of earlier, less trac¬ 
table versions, and so I do not present the code here. Also, that version did not have retraction 
capabilities; except for the ability to handle recursive constraints, it was approximately equivalent 
to the system of Chapter Three. (I attempted to add retraction capabilities, but that interacts in 
extremely complicated ways with dummy instances. 1 chose to abandon that path to concentrate on 
the use of dependencies and on dealing with networks containing multiple contradictions.) 

An obvious problem with the vector construct is the restriction that the size of the vector be 
fixed. One would like to have the size specified by a true constraint variable. One could even set 
up a general ged program that would use a vector of indefinite length; when the ged computation 
was done, the size of the vector would have been determined by the computations of the body 
(trying to satisfy a boundary condition)! This would be very powerful. Implementing this is roughly 
the same as implementing recursive constraints; one needs a way to avoid creating instances of 
tilings until it is clear they they are really needed. In this case, no instances of a vector body would 
be created until one was needed. (This is analogous to a while-do loop: rather than creating 
all the copies of the loop body that will be needed at run time (unrolling the loop), before each 
time the loop body is executed a run-time check is made to determine whether it needs to be.) 
One difficulty that docs arise with vectors is the situation where a vector 5 long is created, and 
then the value 5 is retracted and 3 substituted: two copies of the body must go away, or at least 
become ineffective (the latter course perhaps being more economical implcmentationally if there is 
a chance that the 3 may become a 5 again). Phis requires the ability to retract or suppress network 
connections or constraints; this ability is not provided by the current constraint system. 



A song not for now you need not put stay ... 

A tune for the was can be sung for today ... 

The notes of the does-not will sound as the does ... 

Today you can sing for the will-be that was. 

—Walt Kelly (1953) 

Ten Ever-Lovin' Blue-Eyed Years with Pogo 
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T ill- purpose OF compilation is to trade more work now for less work later, by expending 
effort now to reduce an object to a form more easily dealt with later. In the case of our 
constraint system, we seek to reduce a macro-constraint definition to the definition of a primitive 
constraint. 

I present here a simple compilation technique. While the idea is simple, the details are even 
more tedious than usual, and so I shall not present the code for the compiler here. r ITic compiler 
is similar in flavor to the one described in [Horning 1979], and also bears some resemblance to the 
code-construction teenhiques used in [Brown 1980]. 

The compiler takes a macro-constraint-typc definition and creates an instance of it, in order to 
have a network structure on which to operate. It then performs a propagation-like process on the 
network. 

Suppose the macro-constraint-type to have n pins. Then the compiler performs 2 n passes, one 
for each possible subset of the pins. (This exponential may seem horrendous, but l have compiled 
macro-constraints with nine pins in only a short time—less than thirty seconds.) For each subset, 
those pins are marked “given”, and then pseudo-values are propagated throughout the network. 
A marker is actually a list of pins, and each given pin is marked with a list of itself. A rule may 
be used if markers arc present on all its triggers, in which case the union of the marker sets is 
used to mark the output pin (because all those values went into the deduction of that value). If a 
marker reaches a pin, and the marker is the set of all the given pins, then a rule may be constructed 
relating the output pin to the input pins. Phis is done by tracing back through the “dependencies” 
maintained during the pseudo-propagation, welding together the LISP code for the various rules 
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used in the propagation process. (If a marker reaches a pin and is not the set of all given pins, no 
rule is constructed, because that rule will be obtained on another pass.) If two markers meet at a 
node, then a detector rule may be constructed that signals a contradiction if the two values are not 
equal. 

Assumption cells (and &nogood rules in general) cause difficulties because their cells may 
not be “compiled out” and converted to I.ISF variables. This is because the cell structure is needed 
to record nogood sets. My solution to this (which 1 have not yet implemented—the current com¬ 
piler simply doesn’t handle &nogood rules) is to artificially move interior nodes supplied by 
&nogood rules to the “boundary” of the constraint, making them pseudo-pins. Then they can 
have regular cell structures, but they are not real pins in that they are not ordinary connection 
points. 

As an example of the results of this compilation technique, consider our old standby, the 
temperature converter (this definition is taken from §8.1.2): 

(defcon temp-converter (f c) 

((+ add) f ((* othermult) ((* mult) 9 c) 5 %) 32)) 

The result of compilation is the following primitive constraint definition: 

(DEFPRIM TEMP-CONVERTER (F C) 

(C (F) 

(PROG F00 () 

(RETURN (LET ((A (* (- 32 F) 5)) 

(C 9)) 

(IF (AND (NOT (ZEROP A)) (ZEROP ( C A))) 

(// C A) 

(RETURN-FROM F00 ©DISMISS)))))) 

(F (C) 

(PROG F00 () 

(RETURN ( + 32 

(LET ((A (. C 9)) 

(C 5)) 

(IF (AND (NOT (ZEROP A)) (ZEROP ( C A))) 

(// C A) 

(RETURN-FROM F00 ©DISMISS)))))))) 

There are two rules; one computes c from f and the other computes f from c. Notice that 
where possible straightforward lisp computations are used, as in (* (- 32 f) 5) in the rule 
for computing c from f . If a value is to be used more than once, then a let form is used to name 
the value. The prog forms are necessary so that if a ©dismiss or ©lose operation occurs, an 
immediate exit (via return-f rom) can be taken. If any part of a computation dismisses, then the 
whole thing dismisses; if any part loses, the whole tiling loses. 



Mister Middle in the meadow 
Riddled 'round with rain. 

Puzzle you the pitter-pat 
What not goes up again? 

Riddle you the little dew 
And little do you do? 

Little did is little done. Chapter Ten 

77/o' little did'll do. 

-Walt Kelly (1959) 

The Logo Sunday Brunch 

Conclusions 


T ill: research discussed IN THIS dissertation has resulted in the construction of a con¬ 
straint language system of fair complexity. It certainly docs not have all the characteristics 
one could hope for; it is not even a combination of all the characteristics which have been 
separately achieved by previous systems. It is, however, a fairly efficient version that is perhaps 
closer to being viable for a multiprocessing implementation than any other so far. 

The system presented here performs computations on networks of relationships by local 
propagation, using onc-stcp local deductions. The history of the computation is maintained in 
the form of dependency information, indicating which values were derived from which others. 
This information can be used to explain the computation, in whole or by stages, and to guide the 
automatic or semi-automatic handling of contradictions or changes to the network parameters. This 
uses the technique of dependency-directed backtracking, which is shown to be superior to the usual 
chronological backtracking in many cases. An assumption mechanism is provided to allow guesses 
and default values, and a resolution mechanism plus recording of derived premises as nogood sets 
allows derived constraints to limit the explosion of combinatorial search. 

ITie implementation of the system reflects the structure of the visual image of constraints as 
connected devices which gives this paradigm its intuitive power. This leads to some complexity 
because of the use of data structures with pointers to each other. However, once a network is 
constructed, propagation of values is very fast, and yet the structure of a network can be altered in 
mid-computation without invalidating the semantics of the language. 

A primitive abstraction capability (macros) is provided, and a simple compiler for these mac¬ 
ros can reduce them to primitive operators. 
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10.1. Comparisons with Other Work 


10.1.1. SKETCHPAD Relaxed Constraints on Geometric Diagrams 

The sketchpad system [Sutherland 1963] was in many ways ahead of its time. It provided 
graphic display output, a user interface not limited by the “Model 33 bottleneck”, and automatic 
satisfaction of constraints. A technique amounting to pre-compilation of local propagation paths 
was used (undoubtedly similar to the methods of Chapter Nine), which Sutherland called “the 
one-pass method”. Where that failed, a relaxation method was used, with each constraint being 
represented by a simple subroutine which would calculate an error value as a measure of how 
“unhappy” that constraint was with the existing values. Rxplicit dependency information was 
not used; relaxation solved global conflicts. This was possible because the geometric domain of 
SKETCHPAD is continuous, and all the constraints were equalities among linear relationships of 
variables, so the arithmetic computations were well-behaved. 

Macro-structures could be built within sketchpad and instantiated. Such structures had 
some of the properties of primitive objects, such as designated points of attachment. Moreover, 
non-primitive objects could be identified (merged), in which case sub-parts would be recursively 
merged. The operation of merging was apparently irreversible, however. 

Given that constraints were used as early as 1962, why were not these ideas explored further, 
rather than waiting ten to fifteen years? One might speculate that the ideas were tied to graphics, 
as constraints seem to be most suited for describing objects; and furthermore that the advent of 
timesharing suppressed the development of graphics for a long while (because smooth graphics 
support tends to require steady computational service and therefore a dedicated processor). This 
is pure speculation, of course; but witness the growth of graphics now that personal computers are 
widespread! 


10.1.2. Data Flow Computations Use Parallel Directional Devices 

The data flow languages and architectures proposed by Dennis and his colleagues [Dennis 
1973] [Dennis 1975] [Arvind 1978] are very closely related to constraint languages in that the 
computation is organized as a network of processors operating in parallel on data which moves 
asynchronously along wires between the devices. In the data flow paradigm, however, wires are 
pre-assigned directions along which the data flows. The purpose of data flow is to express the 
sort of directional computations ordinary programming languages handle, without the extraneous 
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sequencing conditions which they impose by their over-restrictive control structures. The data flow 
network itself expresses the necessary and sufficient sequencing for the computation. A device 
computes a result as soon as its arguments are available. 

Data flow networks do not record dependencies. As noted in Chapter Three, however, de¬ 
pendency information can consist largely of knowledge about in which direction data flowed along 
each wire—and this is fixed in a data flow network anyway. 

Dennis has proposed specific architectures for executing data flow programs cffficiently. 
[Dennis 1975] A constraint architecture is of necessity more complex because of its lack of prior 
commitment to the direction of data flow along any given wire. In effect, a single constraint net¬ 
work represents an entire class of data flow programs, one for each partitioning of the network’s 
terminals into input and output terminals; tine constraint system then, in effect, determines dynami¬ 
cally which data flow computation to perform. Therefore it is likely that advances in the theory 
of data flow languages may be used in the implementation of constraint systems. The language 
VAl [Ackcrmann 1979], which is an algorithmic language in the style of algebraic languages but 
permitting flexible handling of sets of values (in particular allowing a function to return more than 
one value without resorting to assignment of rcfccrcnce parameters) is of especial interest. 


10.1.3. Waltz’s Algorithm Filters Scene Labels by Local Propagation 

A local propagation technique is used in [Waltz 1972] (and described also in [Winston 1974] 
and [Winston 1977]) to limit the combinatorial search for Huffman-style labellings of visual scenes 
represented as line drawings. A line drawing itself forms a network structure; the goal is to assign 
a labelling to each junction. The Waltz filtering algorithm propagates information only along lines 
between junctions, and computation is made at each junction only on the basis of information 
flowing in along these lines. Waltz found that this technique, while performing only local propaga¬ 
tion and therefore unable to resolve global ambiguities, would in practical cases usually converge to 
an unique solution or one with very few alternatives to be resolved by global analysis. Moreover, 
it tends to converge quickly, in time closer to linear than exponential in the size of the network. 
Waltz also realized the possibilities for parallel computation in this formulation. (A movie which 
Waltz made, well-known in A1 circles, shows graphically the information propagating from vertex 
to vertex, with ambiguity factors at each vertex rapidly decreasing from the thousands to number 
like 1 or 2.) 

Waltz’s representation has the advantage of simultaneously representing all valid states of the 
system; it has the disadvantage of maintaining no dependency information. This can be a problem 
if the network is ambiguous. For example, suppose that two vertices each have two possible labell¬ 
ings. One might think this would indicate four possible states of the network, but the labellings 
might be correlated in such a way that choosing a label for one vertex forces the choice for the 
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other. Waltz’s system has no way to represent such correlations. (On the other hand, the propaga¬ 
tion technique typically does reduce the number of eases to a number feasible to enumerate and 
explicitly check in order to eliminate miscorrelated cases, which was all Waltz needed.) 


10.1.4. Semantic Networks Propagate Symbolic Fags 

'There is a line of research stemming from Quillian’s work on semantic nets which deals with 
the propagation of symbolic tags, rather than computational quantities, within a network. The 
distinction I draw here is rather fuzzy, but in propagating symbolic mgs it is the fact that two or 
more tags collide somewhere that is of interest, whereas with computational quantities the arrival of 
a single value at a node is of interest. That is, a value carries meaning of its own, while tags arc not 
very interesting in themselves, but bear meaning derived from the places they were first inserted 
into the network. 

Quillian’s semantic nets [Quillian 1968] consisted of a set of nodes representing primitive con¬ 
cepts with pointers among them. The meaning of a node consists precisely of the sum total of its 
relationships to other nodes. Quillian’s system could compare two concepts by propagating two 
symbolic tags from the concepts and analyzing the points where they met. 

Grossman used constraint expressions to represent complex data base relationships, including 
but not limited to unions, intersections, and partitionings of sets. [Grossman 1976] His system 
used complicated, multiple-component tags. One problem with his system was that ever-increasing 
amounts of information are represented in the structure of individual tags rather than in the net¬ 
work, and the structure of a tag was not so easily amenable to analysis and propagation as the 
network. 

Fahlman, on the other hand, explicitly uses only atomic tags, and a small number of them 
at that. The primary use of propagation in ni:tl is to use highly parallel techniques to quickly 
perform set intersection, which is one of the more difficult data base operations. The ability to 
propagate markers quickly in parallel enables the use, in effect, of templates and indirect pointers 
to represent virtual copies of things, rather than making explicit copies; while it takes time to 
follow indirect pointers (one reason I avoided them in the implementation of the macro mechanism 
of Chapter Right), the parallel techniques of netl allow many such pointers to be traced simul¬ 
taneously. 


10.1.5. Freuder’s Method Propagates by Synthesizing Higher-Order Constraints 

In [Freuder 1976] a method is described for propagating constraints by synthesizing new ones. 
The method is roughly as follows. Suppose that a network has n nodes. Let each constraint on 
k nodes (k < n ) be represented as an explicit set of /c-tuples representing valid combinations 
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of values for those nodes. Then all possible subsets of these nodes arc considered, in order of 
cardinality. As k ranges from 2 through n, the constraints of order k (those which relate exactly k 
nodes) arc synthesized from those of order k — 1. More precisely, the order-/c constraint on a set 
of nodes J is synthesized by combining the k constraints of order k — 1 on subsets of J . Hence 
this constitutes a sort of compilation process using a dynamic programming technique. When the 
algorithm is finished, the single ordcr-n constraint is a set of solutions for the entire network. 

The running time of this algorithm is uncertain. On the one hand, a network of n nodes will 
require synthesis of 2” constraints. On the other hand, as Freuder indicates but does not elucidate, 
the entire set of constraints of order A; will contain redundant information if the original constraints 
were all of smaller order. He says, as an example, that in an order-4 network with originally only 
binary constraints, only three ternary constraints need be synthesized. He docs not give a general 
rule, however. He also suggests some general heuristics about which constraints to synthesize first. 

One may observe that Freuder's representation of a constraint amounts to a collection of 
“good sets”, combinations of permissible values, (l ie explicitly assumes that each variable ranges 
over a finite set of values. Note that the same assumption is true of the Waltz application: the 
set of possible labellings for each node is large but finite.) In constrast, the system presented in 
this dissertation initially assumes that all combinations are possible, and then uses nogood sets to 
rule out invalid combinations. When the universe of discourse is finite, this does not make much 
difference; but if it is infinite, then the choice of one representation or the other does matter. 
Indeed, in my system some contortion is needed to represent the fact that a node must take on one 
of a finite number of values; such a fact is enforced by a constraint which, when an invalid value 
ever appears, records that value in a nogood set. In effect, my system is biased towards infinite 
“good sets”, on the principle that until a node is constrained at all it may take on any value. Indeed, 
Freuder uses, for efficiency, a special kind of constraint, which he calls the non-constraint, which 
is in effect the set of all possibilities. He suggests also that the propagation procedure be able to 
deal with complements of sets. It is worth investigating the characteristics of a constraint system 
combining explicit nogood sets with explicit good sets. 1 


10.1.6. PROLOG Uses Chronological Backtracking on Horn Clauses 

The PROLOG language allows the programmer to write statements of predicate calculus in 
Horn clause form. A PROLOG statement is an implication whose antecedent is the conjunction of 
predicates and whose consequent is a single predicate form. A typical PROLOG statement is: 

arrange(cons(X,L),tree(Tl,X,T2)) : - 

partition(L,X,Ll,L2), ar range(LI,T1), arrange(L2,T2). 


1. The oneof mechanism of Chapter Five constitutes an explicit representation of “good sets”, but in a manner not 
well integrated with the representation of nogood sets. 
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(This is taken from a program in [Warren 1977b] that converts between lists and binary trees.) This 
may be interpreted dcclarativcly as the statement 


VXVLVTjVT 2 VLiVL 2 (p(L, X, L h Lz) A a[L u T\) A a(L 2) T 2 )) => a[c{X, L), t{T\,X, T 2 )) 

However, the PROLOG language also provides an imperative interpretation. The term before the 
is considered to be a procedure declaration, and tine terms to the right are statements of the 
procedure. Thus, the statement above may be read, “If you need to call procedure arrange, then 
its first argument must be a cons and its second a tree, and also you must execute three other pro¬ 
cedure calls”. Moreover, there may be more than one “declaration” of a “procedure”; when a pro¬ 
cedure must be executed, its various declarations must be chosen among “non-dctcrministically”. 
(The non-determinism is implemented using chronological backtracking, as in MICRO-PLANNER 
[???]. If a given declaration for a procedure doesn’t work, the next declaration for that procedure is 
tried; if all declarations fail, then failure propagates back to the caller, which must then try a new 
declaration for the preceding term, or fail itself. Sec [Sussman 1972] for a critique of die method of 
ch ronological bac k trac king.) 

The PROLOG language, like the constraint language, provides a secondary interpretation for 
its semantically declarative constructs which is used to limit and guide deductive mechanisms. As 
we have seen in Chapters Five and Six, the non-chronological backtracking mechanism is poten¬ 
tially more efficient than the chronological one used by PROLOG. The PROLOG implementation 
keeps dependency information internally (in a specialized form made possible by the nature of 
its backtracking mechanism, which allows use of a stack), because after merging variables during 
a “procedure call” it may later have to undo the merge on failure. However, this dependency 
information is not available to the user. Conditionals are handled by a resolution pattern-matching 
mechanism and explicit predicates, both of which succeed or fail. The PROLOG compiler manages 
to compile these failure mechanisms out in simple cases, reducing the pattern-matching to simple 
dispatches. 

The best implementation of PROLOG [Warren 1977a] uses data-structurc techniques similar to 
those of the constraint system described in this dissertation. When two variables are identified, one 
is chosen as the “repository” for the value, and the other is made to contain an indirect pointer 
to the first. (It is cleverly arranged that the “oldest” becomes the repository, so that a repository 
cannot be destroyed during backtracking if there is any indirect pointer to it. This is one of the 
tricks enabled by the use of chronological, stack-based backtracking. 2 ) 

There arc many good things about PROLOG, and it deserves more popularity in this country. 
If there were an implementation of PROL OG which had arrays, retained general user-accessible 
dependency information, permitted assumptions, and forsook chronological backtracking, it might 


2. For a discussion of the effects of the slack implementation technique on the development of PROLOG, as well as 
a good general discussion of the pros and cons of the language, see [McDermott 1980], 
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be close to the ideal constraint language I have in mind. Interesting variations of PROLOG allow the 
use of non-Horn clauses [Edcr 1976], and the specification of control information to influence the 
backtracking order in a rather neat and intuitive way [Clark 1980?]. 


10.1.7. THING LAB Provides A Class Hierarchy and Uses Pathnames 

The tiiinglab system [Horning 1979] is a constraint-based graphics system that is quite 
similar in its capabilities to sketchpad [Sutherland 1963]. Its internal organization is different, 
however, and indeed somewhat more flexible. It is embedded within the Smalltalk language 
system (a successor to that described in [Goldberg 1976]) in much the same way that my constraint 
system is embedded within the I Asp Machine LISP system. The SMALLTALK language is object- 
oriented; all computation conceptually occurs by one object passing messages to another. This is, 
therefore, already very similar to a constraint system, the primary (and very large!) difference being 
that the computation is directional in nature. The THING LAB system implements adireetional con¬ 
straint computations, and takes advantage of the SMALLTALK class hierarchy, which allows objects 
to inherit properties from other objects. Horning indicates that the class hierarchy is more useful 
than the sketchpad instance mechanism because Smalltalk instances can have individual state 
variables to parameterize each instance. 

flic thing lab system always compiles a network before beginning to satisfy it; this is done 
for speed. Both propagation and relaxation techniques arc used for constraint satisfaction. While 
thing lab initially used only the error-computation minimization technique of SKETCHPAD, in its 
final form it also has local procedures (analogous to the rules of my system) for explicitly satisfying 
constraints; these were introduced in order to deal with non-numeric constraints (which I think 
might better characterized as “constraints on variables over a discrete domain”). 

No dependency information is retained by tiunglab. Borning states that this causes more 
work to be done than necessary when a parameter is changed. 

Internally, while constraint networks are always compiled, parts arc always accessed at run 
time by following path names; direct connections are not used. Horning points out that this avoids 
die extensive use of back-pointers (complex pointer structures were used in sketchpad and also 
in the system described in this dissertation), at some time penalty for following the paths on every 
access. Another advantage of symbolic pathnames is that the description of a constraint network 
need not be copied every time it is instantiated. This copying is of course a problem with the 
macro mechanism of Chapter Eight: every macro-constraint instance requires a complete copy of 
the defining network. This is necessary because not only must the cells of the instance point to the 
devices of the network, but the devices must point back to the cells. In Burning’s system much less 
copying is done. On the other hand, a system which shares a single read-only description among 
many instances is, I think, less amenable to a multiprocessing implementation. 
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tiiinglab provides a beautiful graphical user interface, and ways of manipulating constraints 
cither as pictures or as SMALLTALK programs. However, it is not a true programming language, nor 
was it intended to be; Borning labels it a “simulation laboratory”. 


10.1.8. I I and ars Analyze Klectrical Circuits by Local Propagation 

The FI. [Sussman 1975] and ARS [Stallman 1977] systems were the direct intellectual ancestors 
of the research in this dissertation, and also inspired much of the other work at M.I.T. to be 
described in the next few sections. These were programs for electrical circuit analysis (actually, ARS 
was an Antecedent Reasoning System in terms of which later versions of El were implemented). 
The various implementations of EL all used local propagation (one-step local deductions) of cur¬ 
rents and voltages to analyze circuits. This is of course a natural application for constraints, as the 
constraint network corresponds directly to the circuit diagram, and inspires a view of constraints 
as active devices. While Sussman and Stallman are quick to point out that local propagation does 
not work for many complex synergistic circuits, they also note that the technique often produces a 
solution much more quickly, directly, and intuitively than the usual technique of setting up node 
or branch equations and then solving a large set of simultaneous linear equations. In effect, in this 
application the local propagation technique automatically determines the best variable to eliminate 
at each step from a set of equations for which the coefficient matrix is sparse. 

el/ ars also kept track of dependency information, using it both for providing explanations 
for the user and for the handling of contradictions by retracting only relevant premises. It was for 
this system that the term dependency-directed backtracking was coined, as well as the notions of in 
and out facts and nogood sets. 

There has been continued work on the application of constraints to circuit analysis and syn¬ 
thesis. [de Kleer 1978b] 


10.1.9. Truth Maintenance Systems Are General Dependency Managers 

From ars developed the notion that there could or should be a general programming system 
or package which could deal with dependencies in a general way, much as a garbage collector 
deals with heap storage in a general way. A series of implementations of a language called AMORD 
were produced at M.I.T. [Doyle 1977] [de Kleer 1978a] The AMORD system provided an indexed 
data base mechanism for recording symbolically represented facts, and a dependencies manager 
called a truth maintenance system ( TMS ) for recording logical relationships among the (otherwise 
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unintcrprctcd) facts. 3 

Jon Doyle [Doyle 1978a] [Doyle 1978b] [Doyle 1979] and later David McAllester [McAllcster 
1978] [McAllester 1980] researched and implemented methods of separating more fully the Truth 
Maintenance System from the data base machinery. Hach deals with nodes , small lisp data struc¬ 
tures which represent abstract facts, bach (act may have a truth value associated with it. One of 
the important results of this work was realizing (or rediscovering) and institutionalizing the distinc¬ 
tion between knowing something not to be true and not knowing something to be true. Thus a 
distinction is drawn between a fact being out (not believed) and being false (believed not). Doyle’s 
I MS implementations allow facts to be cither in or out , and deductions may be made on the basis 
of a fact’s being in or out. Negation (falseness of a fact) is handled by having two nodes, one for 
a fact and one for its negation, and linking them with two rules stating that if one is known to be 
in, then the other must be out. flius the two nodes have four states in all, of which one (both in) 
is forbidden. The other three states correspond to the fact being known true, known false, and 
unknown. 

The ability to make deductions based on not knowing something leads to a peculiar logic. 
Doyle and McDermott have investigated the formal properties of such a logic. [McDermott 1979] 
This structure allows one to express assumptions, for example: one may have a rule stating that if 
the negation of a fact is not known to be true, then the fact may be deduced to be true. 

McAllester’s version of a Truth Maintenance System [McAllester 1978] handles the three 
states true, false, and unknown directly. It also handles assumptions (which McAllester calls 
defaults) in a special way (specially digging certain nodes as being automatically retractable), which 
inspired the methods 1 have used in this dissertation. His system is a little more streamlined than 
Doyle’s, and operates somewhat differently internally. A stripped-down re-implementation of this 
system has been used by Shrobc in the integrated-circuit design system daldai us [Shrobe 1980]. 

I originally set out to use a version of McAllcstcr’s TMS in this research, and re-implementing 
it taught me a great deal. (As it turned out, my re-implementation turned out to be surprisingly 
similar to Shrobc’s: we had both striven to excise the remaining vestiges of the 'I MS’ being tied 
to a particular data base format! 1 find this encouraging: it indicates that a “pure” I MS package, 
properly implemented, will be useful in a number of applications.) 

I decided, however, that it would be more useful not to have to store a value in a cell and 
then make a data structure to represent the fact that the cell had the value. Rather than having 
facts with states true, false, and unknown, it seemed simpler just to let cells have states consisting of 

3. One of my best failures was an attempt to write a simple LISP compiler in an early version of AMORD. The idea 
was that once a program was compiled an incremental change to the program would require only an incremental 
amount of recompilation to produce new compiled code. Ihc use of dependency-directed backtracking would ensure 
that parts of the old compilation effort which did not depend on altered pieces of the program would be preserved. 
The first version of AMORD had a data base organized around triples, much like LHAP, in order to gain some 
imagined speed from a clever implementation technique. (This was my fault, I believe.) It was the attempt to write 
something as large as a compiler in terms of triples that proved the organization to be excessively unwieldy. later 
versions of AMORD have had a richer data base structure. 
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their natural domain (1 chose integers) plus unknown. The resolution techniques McAllcster uses 
generalize in the manner I have shown; one need only think of the I MS as operating on a many- 
valued logic, if one wishes. McAllcster’s 'I MS represents all constraints as clauses, sets of literals 
not all of which may hold (or, at least one of which must not hold, depending on which side of the 
deMorgan coin one looks); since this is the natural form for nogood sets, such sets arc represented 
in the same way as any other constraint, a nice feature. 

Doyle comments in [Doyle 1979] that it is useful to have a way to explicitly represent the 
situation where both a fact and its negation arc believed, and so argues against the use of three- 
valued 'Truth Maintenance Systems. To be sure (Doyle argues), this situation is contradictory and 
so ideally is transient, but nonetheless may persist for some time and must be dealt with. My system 
deals with this issue in that all facts are of the form “cell x has value n \ and there is an explicit way 
to represent the situation where equalities are violated. If one takes a cell and its value to mean rep¬ 
resent the “fact” that the node (in my sense, not the TMS sense of the data structure representaling 
a fact) of the cell has that value, then the various cells of a node can represent possible facts about 
that node. It remains to be seen whether this structure can persist when equalities (connections) 
themselves arc also considered to be questionable and retractable facts. 

McAllcster uses his I MS in [McAllcster 1980], in which he views deducing facts as a process 
of deriving better names for an object than you started out with. 1 have found his ideas tangentially 
useful in trying to choose good names for objects when producing explanations (cf. the function 
cel 1 -goodname in my constraint system). 


10.1.10. A Simple Constraint Language Was Designed Two Years Before This 

In [Steele 1979] Sussman and l described a constraint language system which was the direct 
precursor of the present work. The language allowed creation and connection of devices, and 
provided a macro abstraction facility for defining devices in terms of complex networks. It per¬ 
formed local propagation of values, maintained dependencies, and provided for retraction in case 
of contradictions. It did not have an assumption facility and the corresponding nogood machinery, 
and had no provision for dealing with parts of the network as algebraic expressions, though the 
paper contains some discussion of the possibilities. 

'Flic system in [Steele 1979] did have one interesting and useful feature that the system 
presented here does not (though it would not be that difficult to add): cquatings could be stated not 
only between two cells, but between two constraints of like type. Such an equating implied recur¬ 
sive equating all the corresponding parts (sub-devices, pins, and other variables) of the constraint. 
This of course is similar in intent to the merging facility of SKl-ncilPAD and THING LAB. However, 
those two systems did not maintain dependency information. When dependencies arc maintained, 
some record of the merging must be kept to enter into explanations. In the system of [Steele 1979], 



356 Chap ! nil Ten 


CONCLUSIONS 


this was done by letting the merged objects remain distinct and passing values back and forth over 
an explicit equality link. A more efficient technique would be to merge the two objects into a single 
one, with a notation as to how to undo the process (this is done in tiiinglab) Better yet, some 
analogous thing might be found to do for constraint objects what 1 have done here for cells, letting 
them share a central “repository” structure while maintaining other individual components. 


10.1.11. Other Work Using Constraints 

There arc several lines of research into the applications of constraints. None of these, I believe, 
is aimed directly at the construction of a general-purpose constraint language, but the ideas in 
them are interesting and result from the pressures of a real application of the concept. While the 
work 1 have presented in this dissertation docs not draw directly from all of these, yet it has been 
influenced by the existence of each one, through conversations 1 have had with die authors or 
papers they have written. 

Ken Forbus has used constraints to perform qualitative analyses of situations experiments in 
classical mechanics. He has implemented in MACLISP an efficient and extended version of the 
constraint language used in [Steele 1979], which was written in SCHEME [Steele 1978a]. 

L. Peter Dcutsch, while visiting M.l.T. for half a year, worked on the theory of constraints and 
had many conversations with me. His primary goal (as 1 understand it) was to write a constraint 
system suitable for supporting a text processor, which must have constraints on margins, paragraph 
sizes, and so on. 

Howard Shrobc has used constraints in an integrated-circuit design program [Shrobe 1980], 
and applied dependency analysis to the understanding of computer programs [Shrobe 1979]. 

Luc Steels has been experimenting with constraint propagation within an actors/frame or¬ 
ganization. [Steels 1979] [Steels 1980] Radicr than using a centralized general Truth Maintenance 
System, he lets each constraint have its own arbitrary rules for restoring consistency. He “treats 
a constraint as a propositional object”, but by this he docs not mean what I do when 1 say that 
1 would like a constraint to be an object of the language. In his language, treating the constraint 
as an object means that its value (a truth value) indicates whether or not the constraint is in force 
or not. ( This is similar to my suggestion in §6.3.27 that every primitive constraint have two extra 
pins, one as a conditional control and the other as a biconditional control on whether or not the 
constraint is in force.) What I mean by letting a constraint be an object is that it can be a value, 
rather than having a value, to which constraints can be applied. Of course, adder and maxer 
constraints would not make sense applied to a constraint, but an apply operator or a mapear 
sort of operator would make sense. 

Richard Brown has written an impressive system [Brown 1980] which synthesizes numerical 
programs by constructing a network of constraints, propagating numerical and symbolic informa- 
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tion within it, and then extracting an algebraic description of relevant portions of the network in 
the form of an executable USP program. Brown’s terminology is not at all the same as mine; what 
I call a macro-device he calls a complex device, the term macro-device having a slightly different 
meaning for him: it is a complex device whose definition is a subnetwork which the system extracts 
from a given network in order to explain the relationship between a given set of nodes. Brown 
notes that a complex dev ice is created for every macro-device extracted. 

1 observe that Brown’s macro-devices are generally used in situations where some functional 
relationship must be found between two (or more) nodes so that some other part of the network 
can act as an operator on the function which expresses the relationship; that is, as a constraint on 
a constraint. 1 would find it more natural to let constraints be objects of the language, and express 
his bisection-search other strategies as constraints which take other constraints as arguments. To use 
a mathematical analogy Brown’s system (metaphorically) takes derivatives by accepting a notation 
such as d f{i)/dx , looks at the two places after the d' s, and figures out the functional relationship 
between them, and then takes the derivative of that function. By contrast, 1 would prefer simply 
to write d / and be done with it. To use a programming-language analogy. Brown’s system uses 
Jensen’s device, while 1 would prefer to use functional arguments. A fair amount of Brown’s system 
is devoted to the heuristic extraction of macro-devices; this is necessarily heuristic. It amounts to 
a separation of level from mcta-lcvcl after they have been mixed. I would view bisection-search as 
a “special form” rather than a “simple constraint”. (See [Steele 1978a] and [Steele 1978b], on the 
semantics of USP and SClil-MP, from which I draw my analogies.) 


10.2. Present and Future Work 


10.2.1. fables Can Be Done “The Obvious Way” or by “Algebra” 

By a “table” I mean a data structure which has individual parts into which another object can 
be stored; this includes arrays, record structures, cons cells, character strings (i.c., those which can 
be modified), and so on. I use the word “table” to avoid meaning any one of these specifically. The 
interesting characteristic of a table is that given a table a and a selector k (a number, say), one can 
access a variable which the table associates with that selector. It is important that the selector can 
be variable, i.e., computed. 

One approach to implementing these involves using the obvious sort of internal data structure, 
say an array or a-list, pairing selector values with associated values. One quickly concludes that 
what must be associated with a selector is a cell, for a table can be partially specified, with some 
components having known values and others not. This structure complicates the propagation 
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process. Suppose that a constraint (part x a s) is provided which enforces the relationship 
that the s’tli component of the table a contains the value (i.e., is equated to) x. Then if s becomes 
known, cells containing the table must be awakened, because they may be connected to other 
part constraints which might be interested in the new value. 'I’llis is slightly strange internally 
if one isn’t thinking carefully; in some sense the table has not changed—it is still the same data 
structure—but it has become “more known” than it was before. 'There is a spectrum of known-ncss, 
rather than a dichotomy of known versus unknown. 

There is also a problem when two tables “collide”. Consider the following sequence of state¬ 
ments: 

(part 43 a 1) 

(part 69 b 2) 

( = = a b) 

When the first part constraint is created, presumably (at least, I would do it this way) the variable 
a gets as its value a table whose part named 1 is 43. Similarly b has as value a table whose part 2 
has the value 69. When a and b arc equated, we should expect the two internal table structure to 
be logically merged, so that a and b both have as value the self-same table which has two defined 
parts named l and 2. This is implcmentationally dilTicult to do correctly, expccially so that it may 
be undone. (This is a problem of merging structures which may not have like parts. By the way, this 
is why my system has always had a function called merge-val ues; the intention was that this 
routine would be responsible for merging tables.) 

Notice that the representation of a constraint in my system is actually very much like a table. 
A constraint has named parts. One experimental constraint system 1 have implemented deals 
with a problem of the systems presented in this dissertation, which is that it is not truly order- 
independent with respect to user input, because create statements for a device must precede any 
references to parts of that device. This would seem reasonable; but then again, why should one 
not be able to refer to the a pin of a device not yet specified, expecting to plug it in later? This 
is an essential prerequisite to the ability to have the analogue of functional arguments: constraints 
that operate on other constraints. The experimental system 1 refer to allowed one to make such 
“forward references”. If one referred to (the b foo) and foo was not yet defined to be a 
device, then it was defined to be a b-device, that is, a device whose only property is that it 
has a b pin; such a device has no rules. If one then later referred to (the a foo) then foo 
would also be defined to be an a-dev ice, which definition would then be merged with the 
b-device definition to produce a definition of foo as an a-b-device. When eventually one 
said (create foo adder), the adder definition would be merged with the other, and pins of 
like name identified. This was all very complicated and I was unable to combine it with retraction 
in a straightforward way. 
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The other way to deal with tables is by “algebra”. Rather than having any special value which 
represents a table in a cell, we let the structure of the network represent the table. Thus, if several 
part constraints all have their a pins connected together, than they collectively constitute the 
relevant structure of the table, for they relate selectors to components. All that is needed is a rule of 
algebra that states that if (part x a s) and (part y a v) and s is equal to v then install 
an equating between x and y. Such an equating must be retractable, of course, in case s or v is 
retracted! It also requires the ability to alter the network on the basis of the computation (which is 
what 1 mean when 1 say “algebra”). 4 

While the algebraic method may seem more appealing, the arithmetic (or explicit data struc¬ 
ture) method has the advantage of consolidating, in the explicit table data structure, those connec¬ 
tions which arc of interest to the table identities, distinguishing them from other cquatings to table 
components. 


10.2.2. Recursive Constraint Definitions Require Conditional Expansion 

As discussed in §8.4, the present macro mechanism does not allow the definition of recursive 
macros, because a macro is fully expanded when it is instantiated. Much better would be a 
mechanism analogous to a procedure call, where a macro-constraint is not instantiated until it is 
“called” (i.e., until at least one of its pins is known, or perhaps one of a set of combinations of pins 
specified in or derived from its definition). Gerald Sussman has also suggested that one might want 
to have a more explicit handle on the problem by having a special form, say 

(when var body) 

meaning that the network described by body ought not be constructed until such time as var takes 
on the value true. This is not required to be retractable, however; if var becomes false, the con¬ 
structed network remains. This seems to me a rather brute-force approach, but it does work (1 have 
tried it in one experimental system). 


10.2.3. Explanations Should lake Advantage of the Macro-Call Hierarchy 

In §8.3 1 briefly mentioned the possibility of producing summary explanations by glossing 
over the details of the contents of a macro-device. It is essential that explanations of large computa¬ 
tions be abbreviated to be comprehensible. It is both convenient and natural to use the hierarchy of 
the macro-call hierarchy to guide the summarization process. 


4. I think that there is perhaps a plateau up to which 1 have had trouble scaling the cliff. If any one of tables, 
algebra, or meta-constraints could be handled properly in combination with dependencies and retraction, then the 
others would come through easily. But it is a difficult feat to get any one of these. 
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Doyle [IDoylc 1978a] [Doyle 1979] notes that summaries can be logically represented in the 
form of conditional proofs, from which, once they arc constructed, summary explanations are easily 
produced. However, it is not always clear when it is useful to construct such a conditional proof. 
In the context of the macro-call hierarchy, however, it is natural to summarize the definition of the 
macro-device as a single fact, so that one can say that the computed results depend on the input 
values plus this single fact, which in turn is supported by the conjunction of a large number of facts 
(the definitions and connections which define the macro-device). 

flic current constraint system does not really represent the fact that a value is used by or 
produced by a macro-constraint; the macro-call hierarchy in effect merely provides additional 
names for a node in the form of pins and variables of the macro-constraint. Such pins do 
show up in die dependency structure of the computation, in the list of connections provided by 
why-ul tirnately. What is needed is a mechanism to recognize this fact and omit details of the 
“insides” of a macro-constraint. 


10.2.4. A Constraint Language Should be Meta-Circular 

1 have held as a goal toward the start, that I admit 1 have not even closely approached but 
insist has been a valuable guide in definition and implementation, that a general-purpose constraint 
language should be powerful enough to express an interpreter for itself. (This is the analogy to a 
law which I have often stated in bull sessions, and believe to be original with (though probably not 
unique to) me: A general-purpose programming language isn’t, if it can’t conveniently implement 
itself. An example of one which isn’t is RASIC.) 

First, there need to be appropriate primitive constraints. This causes the constraint language to 
be a meta-language for itself. For example, one might need 

(pin pen) 

which causes p to be equated to the pin named n of the constraint c (compare this with the 
part constraint suggested in §10.2.1). One might also want 

(call c x y z ...) 

to mean that if the value of the variable c is a constraint bar of type foo, then it is as if one had 
written 

((foo bar) x y z ...) 

(This is analogous to the Macl isp function f uncal 1. [Moon 1974]) 

Once the language is sufficiently powerful, then it can be used to express its own interpreter 
(possibly using certain features to express themselves, as when in a LISP interpreter written in LISP 
one writes something like 
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(cond ((eq fun-name 'cons) (cons (car arguments) (cadr arguments))) 
((eq fun-name 'car) (car (car arguments))) 


in the definition of the apply function—it is this property that Reynolds calls meta-circularity. 
[Reynolds 1972]) 

10.2.5. Algebra Is Operating on the Network Structure 

While local propagation can take one very far, there are many situations it cannot handle. I 
believe that the solution is to supplement local propagation with a very limited way of augmenting 
the network structure under computational control to instantiate algebraic identities. These cor¬ 
respond to several ways of viewing the same relationship, where the various points of biew are ex¬ 
pressed as networks with differing structure (and so they express interesting semantic relationships 
betwen the different networks). This is to be distinguished from die ability of the current system 
to take several points of view concerning the same network structure; this is a more syntactic kind 
of algebra that can be performed without reference to the semantics of the constraints, but only 
using die topology of their connections. Ways of introducing multiple points of view are discussed 
in [Sussman 1977] and [Steele 1979]. Richard Brown’s system [Brown 1980] in fact implements such 
algebraic augmentation of die network. One can imagine facilities for pattern-directed invocation 
of algebra rules that would trigger on specified network configurations when new connections were 
made. 


10.2.6. The System May Need Control Advice from the User 

Reality being what it is, sometimes the system’s automatic control structures will thrash wildly 
without some advice from the user on in what order to perform computations. The priority queue 
structure of Chapter Six, for example, provides some automatic control heuristics, but the user may 
need to fine-tune diese. 

An approach I find intriguing might be borrowed from the IC-PROIOG system. [Clark 1980?] 
This version of PROLOG allows one to annotate die argument forms to “procedure calls” to indicate 
that a particular argument is a “lazy producer” of values or an “eager consumer” of them. To 
translate diis concept to the constraint system: a pin of a constraint-type could be labelled by a ? 
(this pin is an eager consumer) or a ! (this pin is a lazy producer). Then rules with triggers labelled 
? would have very high priority when such a trigger received a value; and rules with output pins 
labelled ! would have lowered priority. Moreover, if another constraint’s rule has an output pin 
connected to an eager consumer cell, then that rule has high priority (and diis overrides any ! 
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annotation of that output pin). Using dais annotation scheme one can express co-routines and such 
using recursively defined constraints. 

Another way to control the order of computation is to let every constraint have an extra con¬ 
ditional control pin, as suggested in §6.3.27. 'Then a network of meta-constraints could selectively 
enable and disable constraints via this pin; a disabled constraint would not propagate, and enabling 
would allow rules to be awakened. This technique in particular might be of use in combination 
with algebraic techniques. Very often, in a redundantly specified network, one can determine that 
several subnetworks are duplicating each other’s efforts. This could be detected by pattern-directed 
methods, and an algebra rule triggered that would disable the redundant versions of the network, 
or perhaps just give them low priority. 


10.2.7. Techniques Are Needed for Run-time Storage Reclamation 

One property of the recording of dependency information is that the entire history of the 
computation is maintained. This is an advantage, but it also poses a problem, in that it takes 
memory to hold the history. In a practical constraint system there will need to be ways to reclaim 
data structures which arc unused or likely not to be used. The best candidates for reclamation are 
those structures which can be recomputed if necessary. 

In a constraint system with an abstraction hierarchy, one could reclaim the dependency struc¬ 
tures, and even the networks, for the bodies of macro-constraints, leaving behind the results that 
had been computed from the inputs. (If later the dependency structures are traced, the syustem can 
report: “I computed it using this macro-constraint, whose instance here 1 garbage-collected, but I 
assure you that it was a valid computation—and if you like I will reconstruct the proof.”) If one is 
interested in reclaiming devices, a good choice might be devices whose pins all have values, for in 
some sense they have done all the work they can. ('file appearance and disappearance of devices 
is analogous to the appearance and disappearance of incarnations of a procedure; the incarnation 
appears (perhaps in the guise of a frame on the run-time stack) when the procedure is needed, may 
survive for a while in a co-routining context, and then disappears when it is done.) 

Another possibility is reclamation of nogood sets. There arc at least two cases of interest. One 
is diat resolution may produce a new nogood set that supersedes an old nogood set for some node, 
in that the set of pairs in the new nogood set is a proper subset of that of the old nogood set. In this 
case the old one can be reclaimed. Doing dais efficiently would require a more complex indexing 
structure for nogood sets than I have used here, but would probably be worth a great deal. It would 
certainly decrease the time spent checking nogood sets when solving something like the N queens 
problem as in §6.4. 

Ifie other possibility for reclaiming nogood sets is necessarily heuristic. One would simply 
throw away nogood sets containing values which arc (for some reason) considered to be unlikely 
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to recur. Such nogood sets can always be recomputed if necessary. Perhaps with each nogood set 
might be recorded some measure of the effort that was necessary to compute it, and cheap ones 
might be discarded before expensive ones. Care is needed, of course, to prevent thrashing caused 
by constantly reclaiming and recreating a nogood set. 


10.3. Contributions of This Research 

These are what 1 believe to be the new and original contributions of the research reported by 

this dissertation: 

• 1 attempted to design a complete, general-purpose programming system organized around con¬ 
straints. While this goal has not yet been met, yet I have made some progress toward it. 

• The structure of the implementation matches the imagery of the paradigm. Data structures 
which arc thought of as being directly connected (as for example in a diagram of a network) 
actually are connected. 

(If this point seems trivial, consider two implementations of lisp, one using the usual pointer 
representation, and one operating on S-exprcssions represented in “external form”, as character 
strings. An implementation of the latter form may seem manifestly laughable, but consider: (1) 
McCarthy mentioned the possibility of such an implementation inone of the first early papers 
on lisp. [McCarthy 1960] (2) Church’s lambda calculus [Church 1941], an intellectual precur¬ 
sor to lisp, was defined in terms of manipulations on strings, not trees, of symbols. The tree 
representation had to await computer imnplemcntation. (3) Certain program editors for LISP, 
notably the cousins lmacs [Stallman 1980] (the editor usually used by the MACLISP community 
[Moon 1974]) and /avli (the editor for Lisp Machine lisp [Weinrcb 1979]), represent those 
programs as character strings and yet manipulate S-expressions, as if performing car, edr, 
and consoperations, by manipulating these strings. For some purposes, such as pretty-printing, 
the character string representation is actually more convenient than the pointer representation. 
(Indeed, that is why we write LISP programs as character strings rather than box-and-arrow 
diagrams!) Therefore the string representation is not obviously impractical for all purposes. On 
the other hand, the pointer representation is certainly much more economical for most purposes, 
and this follows our intuitions about explicitly representing interesting relationships (such as car 
and edr) directly. T he points are that (a) alternative representations need to be explored, and (b) 
a representation which conforms to a pictorial image may seem mor£ cumbersome at first but 
may be more efficient because interesting relationships arc represented directly.) 

• The structure of the implementation is closer to being suitable for implementation on multiple 
processors than any other constraint system. (The organization of TllljNGLAB [Doming] might on 
the surface appear to be equally suitable, but the internal use of pa(hnames rather than direct 
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pointers causes problems.) Considerable effort has been made to make small the quanta of 
necessarily indivisible computation. 

• The research was conducted with the principles of order-independence, locality, and monotonicity 
always explicitly in mind. These principles arc essential to the design of a constraint system. 
Order-independence prevents the system from relying on the form of the input; its computa¬ 
tions should be derived from the content only. Locality and monotonicity arc important to the 
conceptual simplicity and comprehensibility of the system. 

• This system deals explicitly with the problem of behaving properly in the presence of contradic¬ 
tions. Just as Doyle and McAllcster had to make the distinction between the truth of a fact 
and the belief in a fact, so I have noted the distinction between the consistency of a system and 
the well-foundedness of the system. Every computation, every deduction made by the system 
presented here is well-founded: each result is validly deduced from given premises. If die 
premises are inconsistent, then the conclusions may be contradictory, but they will nevertheless 
have correct justifications. 

It is important for a constraint system to be tolerant of contradictions; if a problem arises in 
a large system of relationships, the user may not want to deal with the problem immediately. 
He may want to investigate the problem, or work on distantly related parts of the network that 
may be affected by the contradiction only slightly or not at all. Another case, common when 
revising designs for engineered artifacts, is that die user wants to change several parameters at 
once; changing any one would produce a hopeless snarl of contradictions, but if the user can 
only tell the system, “Wait,” then he can make the other changes to make the system consistent 
again. 

Previous Truth Maintenance Systems have been relatively intolerant of contradictions, insisting 
that each one be resolved immediately. The system I have presented is tolerant. The state 
of a network containing contradictions is well-defined, because it is well-founded, and the com¬ 
putation and explanation mechanisms can still behave reasonably and intuitively. Heuristics 
(lowered priority for computing consequences of values known to be in conflict) prevent die 
wasting of computational effort on deductions likely to be retracted soon. 


To God alone be the glory. Amen. 



The Parly of the first Part 
And the party of the next 
Are partly participled 
In a parsley-covered text. 

Were you partial to a Party 
That has parceled out its parts 
With the Party that was second 

In your polly-tickle heart? References 

Then parlay all your losings 
On a horse that's running dark — 

With lights-out you may triple 
In a homer in the park. 

-Wall Kelly (1952) 
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